Hallo Leute, kennt sich jemand mit der Belegung der Datenschnittstelle/Steckkartenschnittstelle bei der Logamatic 2107 aus (sieht aus wie ein kleiner ISA Steckplatz) ? Ich wollte an den Bus um ein paar Parameter (Temp. ...) auszuwerten. Hat sich schon jemand damit beschäftigt ??? Grüße & Danke!
Hi! du meinst diese M292 Busplatine mit den 12poligen Stecksockeln drauf? Ich stehe vor gleichem Problem. Mir wurde, als wir die Heizungsanlage modernisiert haben, vorgeblaht, dass eine Anbindung der Buderus Steuerung an einen PC möglich sei. Später habe ich dann erst bemerkt, dass es dazu ein passendes Modul mit rs232 Schnittstelle (unbezahlbar für den Einsatzzweck wie ich finde) braucht. Dann hat man aber immer noch keine Software und Protokollbeschreibung. Per google habe ich auch schon einige Zeit mit suchen verbracht. Das einzig sinnvolle ergebnis war eine Person in anderem Forum, der einen Datenlogger python daemon geschrieben hat. Setzt aber eben wieder das RS232 Modul voraus. Bei diesem M292 handelt es sich um einen internen Kommuniationsbus zwischen Hauptsteuerung und den (optionalen) Modulen. Wenn man den direkt sinnvoll abgreifen könnte wäre das schon ne geile sache. Ich habe es mittlerweile aufgegeben, mich mit dem Thema zu beschäftigen, da Buderus auch nur ne Firma ist, die Kohle mit Zusatzartikeln machen will. Anfragen über den Heizungsmeister meines Vertrauens gingen ebenso ins leere. Wenn man wenigstens einen Ansatzpunkt hätte, um was für eine Art Bus es sich dabei handelt. Da ich aber weder einen 12Kanal Logic Analyzer habe, noch den richtigen Ansporn, da irgendwas dran zu fummeln lasse ich es lieber bleiben. Falls du (oder jemand anders) dennoch weitere Infos dazu hättet wäre mir das auch sehr recht! Gruss, Malte
Angehängte Dateien:
-
heiz.png
29 KB
Hallo, ich hänge an der RC30 und hoffe das die Logamatic 2107 das gleiche Protokoll fährt. Ich werde das die nächsten Wochen mal bei einer Logamatic 2107 durchmessen ... Das Protokoll der RC30 (am ServiceKey) ist etwas schwer zu lesen, aber die meissten Werte, die ich haben will, werden schon geloggt (siehe Bild). Grüße.
Hi Rudi, na das ist doch schonmal was. Nen ServiceKey scheint die 2107 nicht zu haben. Nur eben diesen internen Bus (sofern man keine Module eingesteckt hat, so wie wir ;) Dein Lila "Was?" Im Graph sieht mir ganz verdächtig nach dem Schaltzustand der Brennerfreigabe aus. Immer wenn deine Kesseltemperatur hochgeht, gibt es auch dort eine entsprechend lange Flanke. Ist das ein Analogwert? Komisch finde ich die verschiedenen Werte der Flanken - hast du einen modulierten Brenner? Das würde die unterschiedlichen Flankenhöhen erklären. Wenn du dich diesem Bus mal annehmen könntest wäre das super, ich habe hier die schematische Darstellung für die Inbetriebnahme (ein spartanischer Schaltplan ohne wichtige Details. Was ich aber sagen kann ist, dass nur die Pins 1-12 des 20poligen Busses verwendet werden (dieser ISA aehnliche stecker hat auch entsprechend nur 2x6 pins. Mehr geht aus dem Schaltbild auch nicht hervor. Gruss, Malte
Hallo, ich gehe direkt von der Service-Key-Schnittstelle (über Klinkenstecker) an meine (Frickel)Schaltung, die das Signal auf einen MCU verträglichen Wert wandelt (3V3). Die MCU kann dann direkt über die UART 9600Baud die Daten empfangen. Das "Was?" sagt eigentlich nur das der Brenner eingeschaltet ist und welcher Kreis geheizt wird (Warmwasser/Heizung). Über einen weiteren Sensor zeichne ich den Gasverbrauch am Zähler auf und kann so direkt bestimmen wieviel Gas für Heizung und Warmwasser verbraucht wurde. Ich habe leider noch nicht die Stellen für den Vor-/Rücklauf der Heizung gefunden. Aber die sollten spätestens in der Heizperiode gefunden werden ... Grüße.
Hi Rudi, ich habe an meiner RC30 keine Service-Key Schnittstelle gefunden. (vielleicht eine ältere Version) Aber an der BC10; ich habe eine Logamatic EMS statt einer Logamatic 2107. Dort habe ich mit meinem Oszi folgendes gemessen: L= GND R= Tx (aus Service-Key Sicht), mit Low Pegel=~11V und High Pegel=~16V GND= ~16V Ist dies bei Dir genauso? Ist dort wo normalerweise GND beim Klinkenstecker ist, vielleicht der Rx Eingang mit einem Pullup an 16V? Magst Du uns oder mir deine Schaltung und das bislang erforschte Protokoll mitteilen? Gruß Malte
Angehängte Dateien:
-
rc30.png
930 KB
Hallo Malte, die Schnittstelle befindet sich hinter einer Platikabdeckung neben den Tasten (siehe Bild). Ist übrigens auch EMS. Belegung: Beitrag "Buderus Bedieneinheit RC30" Ich koppel den DC-Anteil über einen Kondensator aus: -+2.5V und dann per Spannungsteiler auf +-1.5 und dann per Opamp auf 0-3V Pegel. Ist nicht ideal denke ich, aber funktioniert erstmal. Hat jemand eine bessere Lösung ???? An einem Erfahrungsaustausch bin ich sehr interessiert ! Grüße.
> Ist dort wo normalerweise GND beim Klinkenstecker ist, vielleicht der Rx > Eingang mit einem Pullup an 16V? Ich "glaube nicht". Die Teilnehmer senden alle auf dem Bus (TX==RX). Du kannst den Offset auf der Signalleitung für die Stromversorgung benutzen oder die 12V. Wieviel Strom die Leitungen können kann ich dir aber nicht sagen. Grüße.
Ok, das sieht bei mir sehr ähnlich aus. Ich hatte es so verstanden, dass das Teil mit dem größeren Display RC30 heißt und das Teil links daneben mit den beiden Drehschaltern und der Servicekey Schnittstelle BC10 heißt. Eigentlich auch egal wie sie heißen. :-) Danke, das werde ich dann mal ausprobieren. Gruß Malte
Leider habe ich nirgends nen ServiceKey oder ähnliches an meinem Teil (Zubehör zu kaufen ist mir es dann aber doch nicht wert). @Malte: Hallo Namensvetter ;)
@Malte: Moin Namensvetter :-) und Du bist auch nur 11 Tage älter als ich. ;-) Ich glaube hier oben im Norden kommt unser Name häufiger als im Süden vor. Gruß Malte
@Walter: Irgend so ne Buderus Gxx Gastherme mit Logamatic 2107 Steuerung. Allerdings diese Steuerung ohne jegliche Zusatzmodule, da das ganze eine Zentralheizung für mehrere Wohnungen (vermietet) darstellt und somit die pumpenansteuerung ueber buderus-kram zu teuer gewesen waere. Deshalb verwende ich den einen Heizkreis der 2107 nur als Freigabe für die bestehenden Raumtemperaturschalter der alten Anlage (in den Wohnungen). @Malte: ja, denke ich auch - aber ich wohne im Sueden - weiss auch nicht was meine Eltern sich dabei gedacht haben, einen "nordischen" Namen zu nehmen :)
Naja, also von meiner Seite aus nicht, da ich keine Hardware habe um die 12 Pins zu analysieren. Ich vermute (!) mal dass der interne Bus in etwa so aussehen könnte: 12 Pins: V+ GND CLK unknown 8 Datenbits Das kann natürlich auch völlig anders aussehen. Zum beispiel könnte es auch ein serieller Bus sein und die anderen Pins dienen dazu, das jeweils gesteckte Modul zu identifizieren. Keine Ahnung. Solange ich keinen LogicAnalyzer in den händen halte heisst es für mich erstmal warten und hoffen dass jemand anders eine Erleuchtung bekommt :-( Wie gesagt, mit entsprechender Hardware die einen ServiceKey oder direkt das RS232 Modul bereitstellt gibt es ja schon lösungen. Leider sind diese Module beim Hersteller/Heizungsfachbetrieb nicht gerade günstig. Und mal ehrlich, 150-200€ will ich nicht ausgeben, nur um die Daten loggen zu können. Das muss weitaus günstiger machbar sein. Gruss, Malte
Für den Service-Key habe ich jetzt eine mehr oder weniger 1-Chip Lösung, die ich mir demnächst auf eine Platine setzen werde. Grüße.
Moin, ich habe mir nun eine kleine Platine gebastelt und zwei Textdateien mit dem Hyperterminal aufgenommen. Ich habe aber nen LM211 verwendet, der war noch vorhanden. @Rudi: Sieht das so erstmal richtig aus? Oder habe ich noch ein Hardware Fehler? Gruß Malte
Kann du mal im Bus-Monitor schauen welche Module vorhanden sind ? Ansonsten sieht es schon mehr oder weniger nach den Daten aus. Bist du sicher das der LM211 ordentliche Flanken am Ausgang hat ? Ich messe die Zeit zwischen den einzelnen Zeichen um Anfang und Ende einer Nachricht zu ermitteln (ein paar 10ms). Bei mir sieht es z.B. so aus:
1 | 90 00 10 00 |
2 | 90 00 10 00 |
3 | 90 00 10 00 |
4 | 90 00 10 00 |
5 | 89 00 09 00 |
6 | 90 00 98 |
7 | 90 00 10 00 |
8 | 90 00 10 00 |
9 | 90 00 10 |
10 | 2009 8 5 7 : 13 : 58 |
11 | 00 06 00 09 08 07 05 0D 3A 02 01 63 00 |
12 | 90 00 10 00 |
13 | 90 00 10 00 |
14 | TEMP AUSSEN: 18.5 |
15 | 08 00 19 00 00 B9 01 F3 80 00 00 00 00 00 00 B3 72 09 DD 84 00 00 00 08 82 84 00 A7 EB BB 00 |
16 | TEMP WARMWASSER: 51.6 51.6 |
17 | 08 00 34 00 34 02 04 02 04 21 00 00 03 00 01 5B 00 00 0B 87 00 06 00 |
18 | 90 00 10 00 |
19 | 08 00 07 00 03 01 00 00 00 00 00 00 00 00 00 00 00 DA 00 |
20 | TEMP KESSEL: 31.1 1.7 |
21 | 00 |
22 | 08 00 18 00 07 01 37 00 00 00 00 00 60 80 00 02 04 01 35 00 00 11 30 48 00 CB 00 00 00 7A 00 |
23 | 90 00 10 00 |
24 | 90 00 10 00 |
25 | 90 00 10 00 |
26 | 90 00 10 00 |
27 | 90 00 10 00 |
28 | 89 00 09 00 |
29 | 90 00 10 00 |
30 | 90 00 10 00 |
31 | 90 00 10 00 |
32 | 89 00 09 00 |
Ich konnte heute an der Logamatic 2107 messen. Es liegen am Flachbandkabel zur Displayeinheit zwei Signale mit 5V Pegel an, die nach Daten aussehen. Das Signal wird mit etwa 50Khz geschickt. Demnächst wird das Flachbandkabel "richtig" angezapft und dann gibt es mehr. An den 3 freien 12poligen Steckverbindern sieht es eher schlecht aus. Dort liegt nur eins der Signale an. Die Steckverbinder scheinen auch nicht identisch verdrahtet zu sein. Grüße.
Rudi: ich bin mir nicht sicher, ich vermute mal, dass das jeweilige modul welches man in die expansion slots stopfen kann, sich beim logamatic controller erst anmeldet, bevor da was an kommunikation passiert. Das macht das ganze Vorhaben meinerseits schon recht unmöglich. Am Display Daten abgreifen? Hm. ich bezweifle dass da was brauchbares rübergeht - im Zweifelsfall das was gerade angezeigt wird. Ich sollte mich wohl auch nochmal ein paar Stunden in den Heizraum begeben... Grüssle
Hallo, über die Displayeinheit regelst du die Anlage und kannst alle Daten abgreifen. Es müssen alle Daten an diese Einheit geschickt werden (Temperatur etc.). Wenn du die Displayeinheite auf den Kopf drehst sind es die zweiten Pins (oben/unten) von rechts auf denen die Daten geschickt werden (am Flachbandkabel das von der Steuereinheit kommt). Kannst du evtl. mal ein Bild von der Platine machen ? Ich habe leider nur unscharfe mit meinem Handy machen können. Eins von der Displayeinheit und dann noch eins links von den freien Steckverbindern mit dem Steckverbinder für die Temperatursensoren. Dann kann ich das mal einzeichnen. Grüße.
Hi Rudi, aber sicher doch. die bilder findest du hier: http://titan.neo-soft.org/temp/logamatic_2107/ Wollte die nicht hier anhängen (weil viel zu gross), kannst dir das passende selbst rausschnippeln :) Gruss, Malte
Angehängte Dateien:
-
0001.jpg
290 KB
Super! Habe die identifizierten Pins mal gekennzeichnet. Bild 1/3
Super. Jetzt habe ich mir beim foto machen auch mal die displayeinheit angeguckt, da scheint ja die komplette Logik drauf zu sein. Von daher ist das flachbandkabel vielleicht doch der punkt den wir alle zusammen angreifen und vernichten sollten ;-) Dachte die Logik sitzt woanders und das waere nur ne dumme platine mit display und tasten. Schade dass ich im signal reverse-engineeren so wenig erfahrung habe. Wenn du da aber eine art interface dranbasteln koenntest, waere schon sehr viel geholfen! Gruss, Malte
Es wird wohl darauf hinauslaufen das auf das Kabel ein weiterer Steckverbinder gepresst wird (wie bei den IDE Kabeln) um weitere Messungen durchzuführen. Was mir etwas Kopfschmerzen bereitet sind die 50KHz Signal. Das passt irgendwie nicht.
Ja, weiterer Steckverbinder ist die einfachste Lösung. Was ist an 50 KHz verkehrt? Klar, die passen nicht zu 9600 baud, aber ich gehe mal nicht davon aus dass das signal unbedingt dem des ServiceKeys entsprechen muss. Oder meinst du, dass die nur einen internen Datenkanal im gesamten System haben und diesen als Abgriff auf den ServiceKey geben? Mich nervt das irgendwie gerade dass ich nur theoretisch mitdiskutieren kann - will auch endlich was produktives dazu beitragen.
Hi, ich habe im Bus Monitor nachgeschaut. Ich habe anscheinend nur drei Module: UBA3 / MC10 8 BC10 9 RC30 16 Mit der Flankensteilheit bin ich mir nicht sicher, die muss ich noch mal überprüfen. Die Texte "TEMP AUSSEN: 18.5" werden aber nicht so direkt übertragen? Die hast Du interpretiert und eingefügt, oder? Was steht dann da, an der Stelle? Danke und Gruss, Malte
Hallo, die 3 Module sind ok. Die Texte habe ich interpretiert, klar. 18.5°C wären im Hex-Dump dann "00 B9". Ich bin mir nicht 100%ig sicher, aber ich glaube am Ende kommt noch eine CRC. Die habe ich mir bisher aber noch nicht genau angesehen. Ich werde wohl nächste Woche die Platine malen und abschicken, falls du interesse hast, dann kann ich dir eine mitmachen. Ich benutze einen Komperator der im Bereich 3V-5V arbeitet, aber an den Eingängen bis zu 22V verträgt. Der Ausgang ist dann direkt im VCC-Level. Grüße.
Hi, ich habe mit einem anderen Notebook Daten aufgezeichnet. Die Daten sehen nun schonmal ähnlicher aus. Was ist der Newline Character? FF? Was kostet denn so eine Platine? Hier sonst meine Email: hoelkynkoelkyn (aet) gmx (punkt) net Gruß Malte
Hallo, dieses 0xff sehe ich bei mir nicht. Auf dem Oszi ist nach den Daten auch kein Start/Stop-Bit für ein 0xFF. Sieht eher wieder nach zu langsamen Flanken aus !? Hast du einen Warmwasserboiler mit dran ? Deine Anlage zeigt beim Druck nur 0xff an. (0x08 0x00 0x18 ... die Stelle 21). Die Platine wird nicht mehr als 10€ kosten, eher weniger. Ich melde mich per E-Mail wenn sie fertig ist. Grüße.
Hallo, ich interessiere mich auch für den BUS. Habe gerade auch herausgefunden dass die Daten nur seriell übertragen werden. Bis Mein OSZI geknallt und geraucht hat. Würde mich für die Schaltung oder Platine auch interessieren. Natürlich möchte ich auch mithelfen die Daten zu dekodieren und die Software zu entwickeln... meine Mail: if38(at)arcor(punkt)de Ich hatte eigentlich vor mir irgendwas zu basteln um die RC30 zu ersetzen um z.B. am PC die Heizprogramme schnell zu ändern ohne die rumdreherrei an der RC30. Sehe jedenfalls nicht ein 240€uro für Service-Key und Kabel und nochmal 480Euro für die Software auszugeben. Gruß Ingo
Hallo, ich habe mir auch gerade die Kommunikation auf dem EMS-Bus an der Service-Buchse mitgeschnitten Habe mal die decodierten Daten Telegramme bei mir gesucht und vermutlich gefunden. habe meine Telegramme sind die unteren. Nach dem Trennstrich stehen meine ermittelten ergebnisse. Die Außentemperatur scheint nicht ganz zu stimmen. Das Telegramm mit der "Temperatur Warmwasser" ist bei mir ein Zeichen kürzer. Das erste Byte scheint wohl jeweils die BUS-Adresse zu sein die man in der BC30 sehen kann. Wenn man an der RC30 z.B. die Temperatur verstellt tauchen Telegramme mit 0x10 auf (RC30 Adresse =16)
1 | TEMP KESSEL: 31.1 1.7 | 27.2 1,2 (RC30=28°C) |
2 | 08 00 18 00 07 01 37 00 00 00 00 00 60 80 00 02 04 01 35 00 00 11 30 48 00 CB 00 00 00 7A 00 |
3 | 08 00 18 00 07 01 10 00 00 00 00 00 60 00 00 02 22 01 17 00 00 0C 30 48 00 4B 7F 00 00 5F 00 |
4 | |
5 | TEMP AUSSEN: 18.5 | 1,3 (RC30=15°C) |
6 | 08 00 19 00 00 B9 01 F3 80 00 00 00 00 00 00 B3 72 09 DD 84 00 00 00 08 82 84 00 A7 EB BB 00 |
7 | 08 00 19 00 00 11 01 13 00 00 00 00 00 00 00 64 6F 0A 41 2C 00 00 00 09 25 1C 00 4F 76 0C 00 |
8 | |
9 | TEMP WARMWASSER: 51.6 51.6 | 54,6 54,6 (RC30=55°C) |
10 | 08 00 34 00 34 02 04 02 04 21 00 00 03 00 01 5B 00 00 0B 87 00 06 00 |
11 | 08 00 34 00 0A 02 22 02 22 00 00 01 03 7F 01 1C 10 00 14 79 44 00 |
Hier also meine Kabel: Habe die Infos zur Service-Buchse hierher: Beitrag "Buderus Bedieneinheit RC30" LINKS : GND RECHTS: SIGNALOFFSET +12V, +-2.5V Signalpegel (etwa) GND : +12V Da die Serielle Schnittstelle mit +-12V arbeitet und auch mit weniger auskommt habe ich mal versucht die +-2,5V aus dem Service-Stecker zu nehmen. Also GND (SubD9 Pin5) auf die +12V gelegt und auf RX (SubD Pin2) auf "rechts" gelegt. Das TerminalProgramm habe ich auf 9.600 7 Even 1 eingestellt. Kann es vielleicht sein dass der Dignosestecker bei GND auch wirklich GND(0V) hat und auf Rechts das Signal(+-2,5V) und auf Links -12Volt? Wenn nicht könnte es vielleicht Probleme geben wenn ein Rechner ans Stromnetz angeschlossen ist. Ich habe mein Notebook mit serieller Schnittstelle verwenden und über Batterie laufen lassen. Der mittlere Kontakt und die Spitze scheinen die beiden Kabel zu sein die zur RC30 gehen. @Rudi: Wie hast Du denn das Bild mit den Werten hinbekommen? Ist das ein Programm dass Du selber geschrieben hast? Könnte man da schon mal eine Testversion bekommen? Gruß Ingo
Hallo, schön das es noch ein paar Leute gibt ! > Kann es vielleicht sein dass der Dignosestecker bei GND auch wirklich > GND(0V) hat und auf Rechts das Signal(+-2,5V) und auf Links -12Volt? Nein, GND ist GND und von da gemessen sind die Signale so wie sie offensichtlich sein sollen. Wenn du die 12V als GND Potential genutzt sind es dann +-2,5V. > Wie hast Du denn das Bild mit den Werten hinbekommen? Ist das ein > Programm dass Du selber geschrieben hast? Könnte man da schon mal eine > Testversion bekommen? Mit gnuplot, wie gesagt schreibe ich die Daten in eine Datenbank und werte sie dann aus. Anbei noch ein Teilweises Skript ür meine Werte die ich bisher Ermittelt habe (halt der Index!): if ord(data[0]) == 0x08 and ord(data[2]) == 0x18: t1 = ((ord(data[5])<<8)|ord(data[6]))/10.0 data_container.D_DB_TEMP_KESSEL = change_value( D_DB_TEMP_KESSEL , data_container.D_DB_TEMP_KESSEL, t1 ) t2 = ord(data[11]) data_container.D_DB_CIRC = change_value( D_DB_CIRC , data_container.D_DB_CIRC, t2 ) t3 = ord(data[21])/10.0 data_container.D_DB_BAR = change_value( D_DB_BAR , data_container.D_DB_BAR, t3 ) print "TEMP KESSEL:",t1,t3 if (ord(data[11]) & 0x04) == 0x04: print "BRENNER", if (ord(data[11]) & 0x80) == 0x80: print "ZIRK", if (ord(data[11]) & 0x40) == 0x40: print "HK/WW", if (ord(data[11]) & 0x20) == 0x20: print "HK Pumpe", print "%02X" % (ord(data[11]) & ~0xe0) if ord(data[0]) == 0x00 and ord(data[1]) == 0x3D: if ord(data[2]) == 0x02: t1 = ord(data[3])/2.0 data_container.D_DB_TEMP_RAUM_GEST = change_value( D_DB_TEMP_RAUM_GEST , data_container.D_DB_TEMP_RAUM_GEST, t1 ) print "TEMP RAUM GEST.:",t1 if ord(data[2]) == 0x07: if ord(data[3]) == 0x00: print "Einst. Nacht" if ord(data[3]) == 0x01: print "Einst. Tag" if ord(data[3]) == 0x02: print "Einst. Auto" if ord(data[0]) == 0x08 and ord(data[1]) == 0x33: if ord(data[2]) == 0x02: t1 = ord(data[3])/1.0 data_container.D_DB_TEMP_WASSER_GEST = change_value( D_DB_TEMP_WASSER_GEST , data_container.D_DB_TEMP_WASSER_GEST, t1 ) print "TEMP WASSER GEST.:",t1 if ord(data[0]) == 0x08 and ord(data[2]) == 0x19: t1 = ((ord(data[4])<<8)|ord(data[5]))/10.0 data_container.D_DB_TEMP_AUSSEN = change_value( D_DB_TEMP_AUSSEN , data_container.D_DB_TEMP_AUSSEN, t1 ) print "TEMP AUSSEN:",t1 if ord(data[0]) == 0x08 and ord(data[2]) == 0x34: t1 = ((ord(data[5])<<8)|ord(data[6]))/10.0 data_container.D_DB_TEMP_WASSER_WARM_1 = change_value( D_DB_TEMP_WASSER_WARM_1 , data_container.D_DB_TEMP_WASSER_WARM_1, t1 ) t2 = ((ord(data[7])<<8)|ord(data[8]))/10.0 data_container.D_DB_TEMP_WASSER_WARM_2 = change_value( D_DB_TEMP_WASSER_WARM_2 , data_container.D_DB_TEMP_WASSER_WARM_2, t2 ) print "TEMP WARMWASSER:",t1, print "",t2 if ord(data[1]) == 0x3e and ord(data[2]) == 0x00: t1 = ord(data[7])/10.0 data_container.D_DB_TEMP_RAUM = change_value( D_DB_TEMP_RAUM , data_container.D_DB_TEMP_RAUM, t1 ) print "TEMP RAUM:",t1 if ord(data[0]) == 0x00 and ord(data[1]) == 0x06: print 2000+ord(data[3]),ord(data[4]),ord(data[6]),ord(data[5]),":",ord(data[7] ),":",ord(data[8]) dump(data,len(data)) Have Fun!
> Ich hatte eigentlich vor mir irgendwas zu basteln um die RC30 zu > ersetzen um z.B. am PC die Heizprogramme schnell zu ändern ohne die > rumdreherrei an der RC30. Sehe jedenfalls nicht ein 240€uro für >Service-Key und Kabel und nochmal 480Euro für die Software auszugeben. Ich sniffe nur um den optimalen Punkt für den Einsatz der Holzheizung zu ermitteln. Steuerbefehle senden ist mir zu heiss ...
Angehängte Dateien:
-
delete.jpg
87 KB
> Würde mich für die Schaltung oder Platine auch interessieren. Natürlich > möchte ich auch mithelfen die Daten zu dekodieren und die Software zu > entwickeln... Ich habe grad 2 (mini) Platinen im der Queue. Es ist aber keine Potentialtrennung vorgesehen. Der Kern der Schaltung ist ein ADCMP370. Anbei noch der Schaltplan.
Also hat eine weile gedauert den Text zu formatieren und zu verstehen. Das ist ja schon ein paar wichtige Daten. Beim selber senden geht es mir auch mehr um die Heizungsprogramme mal eben und schnell am PC zu erstellen. Mehr will ciha cuh garnicht in die Regelung eingreifen. Mal sehen ob es irgendwann klappt. Im Moment denke ich an einen Datenlogger mit USB-Anschluss zum Loggen der Daten den man parallel zur RC30 anklemmen kann. Vermutlich würde ich es dann als CSV-Datei abspeichern. Dafür nehme ich wohl einen PIC und ein fertigen USB-PortAdapter für den USB-Stick. Vielleicht kann man ja beide Schaltungen zusammenschmeissen.. Habe vor auch einen Datenlogger für die Heizung in JAVA zu schreiben. Mit modelledit.rc-sim.de habe ich ja schon mal ein paar Erfahrungen sammeln können. Vielleicht hat ja jemand Lust am Programm mitzuarbeiten. Gru0ß Ingo
Wie kann man hier eigentlich die letzte "zitieren"? Also alles das was grün ist....
> Vielleicht kann man ja beide Schaltungen zusammenschmeissen.. Da habe ich kein Interesse dran. Ich werde einen Netzwerkkontroller benutzen (z.Z. sendet noch ein PC die Daten an den Server) und die Platine einfach an das Board anschliessen. > Vermutlich würde ich > es dann als CSV-Datei abspeichern. Das kann ich dir bei der Datenmenge nicht empfehlen. Es sei denn dir reichen die letzten Tage und der Rest wird gelöscht. Ich speicher alles in die MYsql Datenbank und visualisiere mit Gnuplot die letzten 3 Tage. Für Berechnungen ist eine einfache SQL-Anweisung, die dann über die letzten Monate/Jahre geht, das Optimum. > Habe vor auch einen Datenlogger für die Heizung in JAVA zu schreiben. > Mit modelledit.rc-sim.de habe ich ja schon mal ein paar Erfahrungen > sammeln können. Vielleicht hat ja jemand Lust am Programm mitzuarbeiten. Ich bin da eher für eine automatisierte Lösung, die mir dann per Webinterface die Daten liefert die ich brauche ;-) Grüße.
> Wie kann man hier eigentlich die letzte "zitieren"? Also alles das was > grün ist.... Einfach per Hand ein "> " vor die Zeilen schreiben oder im Forum anmelden.
> Ich bin da eher für eine automatisierte Lösung, die mir dann per > Webinterface die Daten liefert die ich brauche ;-) Das hört sich ja super an... Aber dann muss man ja immer einen PC laufen lassen, oder gibt es da auch andere Möglichkeiten? Gruß Ingo
> Das hört sich ja super an... Aber dann muss man ja immer einen PC laufen > lassen, oder gibt es da auch andere Möglichkeiten? Ein PC bzw. ein kleiner Rechner muss laufen.
> Also hat eine weile gedauert den Text zu formatieren und zu verstehen. > Das ist ja schon ein paar wichtige Daten. Es ist Python, sollte aber keine Probleme beim Lesen geben. Ist halt rapid prototyping und die Rechner-Performance ist dafür soweit okay. Grüße.
Angehängte Dateien:
-
x11.jpg
66 KB
So, Platine ist gekommen. Ich stell mit vor die direkt ins Kabel zu bauen, sprich per Schrumpfschlauch zwischen den beiden Kabelenden zu integrieren.
Hallo, dank der hier stehenden Informationen bin ich mit der Auswertung der Daten ein Stück vorwärts gekommen. Vielen Dank dafür. Problematisch sehe ich noch die Auswertung der Telegrammlänge. Das Messen der Pause zwischen 2 Telegrammen funktioniert mit dem WindowsPC nur unzuverlässig. Gibt es eine andere Möglichkeit, den Beginn und das Ende eines Telegramms festzustellen? Ich kann keine Start- oder Ende-Bytes erkennen. Wie machen die das? Irgendwelche Ideen? bye, Mario
ich vermute mal dass es einen telegrammheader gibt, der die gesamtgrösse des telegramms definiert?
Hallo, das mit der Laengenangabe im Header muesste man doch aber sehen. Hier mal ein mitgeschnittenes Telegramm mit den bisher ermittelten bzw vermuteten Bedeutungen zur Diskussion: 08 00 18 00 2F 01 C3 64 00 01 01 20 60 80 00 02 14 01 C1 00 01 0D 30 59 00 CC 00 00 00 F7 00 Byte0: Absenderkennung Byte1: Byte2: Funktionstyp ? Byte3: Byte4: Kesseltemp.Sollwert Byte5+6: Kesseltemp. Istwert Byte7: vermutl.Betriebsart Byte8+9: vermutl.Abgastemperatur Byte10+11: Brennerstatus Byte12+13+14: unbekannt Byte15+16: Warmwassertemp. Byte17+18: Rücklauftemp. Byte19+20: unbekannt Byte21: Wasserdruck Byte22+23: unbekannt Byte24+25: Anlagentemp. Byte26: unbekannt, immer 00 Byte27: vermutl.Betriebsart Byte28: unbekannt, immer 00 Byte29: Checksum Byte30: unbekannt, immer 00 Für die Länge des Telegramms ist kein passender Wert vorhanden. Irgendwelche Ideen?, Mario
Sind Byte1 und Byte3 immer 00? Was kommt denn für ein Datensalat vor und nach dem Telegramm, kann es vielleicht sein dass das Protokoll ein stop und Startcode im Telegrammstil verschickt? Ich kann mir schwer vorstellen, dass Start/Stop eines Telegramms nur über Zeitfenster gemacht wird wenn die telegramme unterschiedlich lang sind. Leider habe ich jetzt aber auch nicht wirklich ne weitere Idee, vielleicht könnte mal jemand nen BUS dump über ein paar minuten hier reinposten, so dass ich mich damit auch mal befassen kann (habe ja bisher noch nicht die möglichkeit, die logamatic direkt anzuzapfen hier...) Gruss, Malte
Sodele. Ich werde aus dem geposteten Dump von Malte (ich werd schizophren) noch nicht ganz schlau. Ich habe mich aber gerade nochmal über das Kabel zur Bedieneinheit (direkt an der Logamatic 2107) hergemacht. Bewaffnet mit Oszilloskop bin ich jetzt mal soweit gekommen und stelle das mal zum Brainstorming: Es geht um das 26polige Flachbandkabel, dort habe ich einen dritten Stecker draufgecrimpt und mal fleissig gemessen. Pinangaben beziehen sich auf den roten draht als Pin #1. Gemessen habe ich immer gegen Pin2 als GND
1 | 01 +5V - Versorgungsspannung? An der stelle steht ein "+" auf der Platine |
2 | 02 GND |
3 | 03 5V gemessen, vielleicht ein binärer E/A? |
4 | 04 5V gemessen, vielleicht ein binärer E/A? |
5 | 05 0V gemessen, vielleicht ein binärer E/A? |
6 | 06 0V gemessen, vielleicht ein binärer E/A? |
7 | 07 NC / Nicht an der Platine angeschlossen, gemessen 50hz 0,4V AC (also nix) |
8 | 08 0V gemessen, vielleicht ein binärer E/A? |
9 | 09 0V gemessen, vielleicht ein binärer E/A? |
10 | 10 0V gemessen, vielleicht ein binärer E/A? |
11 | 11 0V gemessen, vielleicht ein binärer E/A? |
12 | 12 0V gemessen, vielleicht ein binärer E/A? |
13 | 13 0V gemessen, vielleicht ein binärer E/A? |
14 | 14 0V gemessen, vielleicht ein binärer E/A? |
15 | 15 TTL Signal Low-Aktiv, feste Pulsbreite, unregelmässiges Signal, könnte Frame start interrupt sein |
16 | 16 TTL Signal variable Pulsbreite, sieht nach Datenübertragung aus |
17 | 17 TTL Signal variable Pulsbreite, sieht nach einem Enable Signal aus |
18 | 18 TTL Signal variable Pulsbreite, sieht nach einem Enable Signal aus |
19 | 19 5V gemessen, vielleicht ein binärer E/A? |
20 | 20 5V gemessen, vielleicht ein binärer E/A? |
21 | 21 0V gemessen, vielleicht ein binärer E/A? |
22 | 22 TTL Signal variable Pulsbreite, sieht nach Datenübertragung aus |
23 | 23 Datenübertragung Differential zu pin 24 |
24 | 24 Datenübertragung Differential zu pin 23 |
25 | 25 50hz sinus der fast wie dreieck aussieht 0,16V AC gemessen, ab und zu störungen messbar |
26 | 26 NC / Nicht an der Platine angeschlossen, identisches Signal wie bei Pin 25 |
Meiner Meinung nach sollte man mal Augenmerk auf die Pins 15-18 legen. Mir ist beim Vergleichen verschiedener Signale zueinander (2. Kanal am Oszilloskop) auffgefallen, dass Flanken unterschiedlicher Signale immer gleichzeitig auftreten. Ich gehe deshalb davon aus, dass die Datenübertragung asynchron funktioniert, ich habe nirgendwo ein clock signal gefunden (feste frequenz). Das einzige Signal mit fester Pulsbreite ist Pin15, kann aber kein Clock sein, ich vermute aber dass mit diesem Signal ein Frame start auf anderen Datenleitungen (würde zu Pin16 passen) darstellt. Leider bin ich halt immer noch nicht im Besitz eines Logikanalyzers. Mehr aussagen kann ich deshalb nicht machen :( Gruss, Malte
Also so weit ich gesehen habe werden immer 2Byte verschickt. das erste Byte ist die BUS-Adresse und das zweite meistens 0x00 oft kommen auch telegramme mit Werten von 0x80 oder größer mit dem zweiten Wert 0x00 gesendet werden. Vermute mal dass es wohl Kollisionen von zwei Busteilnehmern sind. Also wenn man was senden möchte werden vermutlich erst mal die zwei Byte geschickt und gleichzeitig mitgelesen. Wenn Beide Werte gleich sind wird weitergesendet. Oft treten auch nur 2Byte Telegramme auf wie 0x09 0x00 und 0x10 0x00. Sieht wohl ao aus als ob dass dann vielleicht ein "Hallo ich lebe noch" ist. Prüfsummen oder Telgrammlängen konnte ich nicht finden. Das dritte Byte scheint (meistens) der Telegrammtyp zu sein. Also müsste man sich eine kleine Tabelle anfertigen aus der man mit den zweiten bis vierten Byte die Telegrammlänge ablesen kann. @Malte: würde fast vermuten dass Pin 23 und 24 auch so eine Art BUS ähnlich dem Service-Stecker darstellen, oder? Gruß Ingo
Ja, das hatte Rudi schon "vermutet" - er meint aber es waeren 50KHz signal. Kann ich nichts zu sagen, da ich nur einen 2kanal echtzeit LA habe (oszilloskop ;) Aber mich hat es eben nicht in ruhe gelassen, habe mich gerade nochmal im Heizraum vergnügt und versucht die logikpins zuzuordnen. Es hat sich jetzt herausgestellt, dass
1 | 09 Ausgang Heizkreis1 Pumpe (an=5V, aus=0V) |
Also kann man getrost davon ausgehen, dass es auch TTL Ausgänge (und vielleicht auch Eingänge) gibt. Speicherladepumpe konnte ich noch nicht ermitteln. Muss mal die Temperatur hochregeln, damit der schaltet. "Brenner An" ist kein digitaler Ausgang! Der Befehl scheint per BUS übermittelt zu werden, also sucht nicht danach. Ich versuche mal demnaechst, ob ich die TTL Datenleitung mittels MAX232 abhören kann. Gute Nacht, Malte
Timing Log ? Kein Problem ! (ist bzip2 komprimiert und reiner text) Aufbau: C2CTIME TIME CHAR C2CTIME: char to char time (gemessene Zeit zwischen den Zeichen) C2CTIME: 1318 90 # timeout neue msg (char 0) C2CTIME: 104 00 # (char 1) C2CTIME: 218 10 # (char 2) C2CTIME: 218 00 # (char 3) C2CTIME: 1941 89 # timeout, zeichen ist gehört zu neuer msg 90 00 10 00 # log output (4 zeichen) usw. Leider kann ich bisher nur über die Zeit ein Frame erkennen. Es ist bestimmt etwas anders und die Module senden mit unterschiedlichen Zeiten (siehe dieses Beispiel). Der Timeout liegt bei 350. Grüße.
Mario wrote: > Problematisch sehe ich noch die Auswertung der Telegrammlänge. Das > Messen der Pause zwischen 2 Telegrammen funktioniert mit dem WindowsPC > nur unzuverlässig. Ich habe es direkt mit einem uC gemessen (50mhz cortex) und dann die Daten mit der Zeit über die Serielle an einen PC geschickt. Die Zeiten sind alle im sub-ms bereich, also nicht praxistauglich für einem PC. Ich hoffe ja noch das es sich um eine CRC in den Daten handelt. Ich gehe davon aus das die 2 bytes ein Modul ansprechen und dann dieses Modul in einer gewissen Zeit antwortet oder auch nicht. Evtl. liege ich da auch falsch. Grüße.
Malte wrote: > Ich versuche mal demnaechst, ob ich die TTL Datenleitung mittels MAX232 > abhören kann. Ich werde parallel per uC über den ADC die Daten sampeln. Leider nur 1 Kanal, sollte aber auch etwas zu sehen und zu diskutieren geben. Ich habe evtl. am Fr. wieder einen "Termin" beim Kumpel der die Heizung sein eigen nennt ... Bei meinen vorherigen Tests mit dem Scope konnte ich leider keine Start und Stopbits erkennen. Grüße.
Hallo, das Modul für die Logamatic 2107 ist ja das KM271 um eine serielle Schnittstelle zu erhalten. Vielleicht hat ja jemand so ein Modul und kann uns mal ein hochauflösendes Fotos schicken - vielleicht kann man dann erkennen welche Leitungen auf dem Bus benutzt werden und evtl sogar welche Hardware für die Pegelanpassung verwendet wird. Martin
Also ich schaue mir mal Pin16 und 22 an. Da es sich dort um TTL Level handelt gehe ich fast schon davon aus, dass es sich um eine serielle kommunikation zwischen dem Bedienpanel und der Hauptplatine handelt. Wenn dem so ist hätten wir ja schon fast den jackpot. Pin23/24 sieht ja wirklich so aus wie du den ServiceKey beschrieben hast. Auch vom Bild auf dem skope her sieht es wie ein bus aus - ne weile ruhe und dann kurze bursts mit variabler pulsbreite. Aber mal zurück zum Protokoll: ich habe mir gerade mal die EBUS Spezifikation angeschaut, aber laut euren beiden BUS Logs hat das nicht viel damit zu tun: >ACK = 00h >NACK = FFh >SYN = AAh >QQ ZZ PB SB LEN DB1 DB2 DBn CRC (ACK) SYN @Malte Kippis: Deine beiden geposteten Logs sind schrott oder? Jedenfalls unterscheiden die sich gravierend von Rudi's Capture... Gruss, Malte
Angehängte Dateien:
-
buderus2107-bus.jpg
20 KB
Hallo, ich habe vor einiger Zeit die Busplatine mal durchgemessen. Hier meine Ergebnisse: K1 - Relayplatine und zur CPU K2 - FM241 - Mischer 1 1-15 2 1-8 3 1-19 4 1-12 5 + 6 1-9 7 1-6 8 1-3 9 1-18 10 1-2 11 - 12 1-13 K3 - FM242 - 2. Stufe (klein) 1 X 2 1-6 3 1-7 4 1-2 5 + 6 1-9 7 X 8 X 9 1-5 10 1-17 11 - 12 1-13 K4 - FM271 oder FM244 - Kommunikation oder Solar 1 1-13 (24V-) 3* 2 1-20 schwingt 3 1-16 4 1-14 5 1-12 2* 6 + 5V+ 7 1-9 (24V-)3* 8 1-10 siehe 20 schwingt 9 1-6 3* 10 1-4 11 1-2 3* 12 - - unten -? oben +? - = - + = 5V+ 1-9 = 24V+ 1-13= 24V- Kollektorfühler FSK unteren Speicherfühler FSS Martin
Hallo, hiermit müsste sich ja feststellen lassen welche Pinne auf dem Flachbandkabel auch an den Steckplatz K4 gehen (siehe Malte Bayers Messungen) - ich sehe da im Moment 1-10 und 1-20 als Kanditaten. Leider hatte ich damals kein Scope zur Verfügung um genau zusehen wie das "Schwingen" aussieht. Evtl ist es ja ein einfacher RS485 auf RS232 Wandler. @Malte - vielleicht kannst du mal nachmessen welche Pinne des Flackbandkabels auf die Pinne 1-10 und 1-20 der Relay Platine gehen die auf die Bus Platine geht. Martin
Hallo, >Aber mal zurück zum Protokoll: ich habe mir gerade mal die EBUS >Spezifikation angeschaut, aber laut euren beiden BUS Logs hat das nicht >viel damit zu tun: Die Ausgabe des Service-Keys den man bei Buderus kaufen kann ist auch komplett anders und ähnlich Deinem Geposteten LOG. Wenn man aber direkt an den Stecker geht und auf den BUS-hört kommen die geposteten Logs heraus. Der Service-Key (und wohl auch der RS232Gateway für den EMS-Bus) setzen dann die Befehle auf den BUS um. Ist also kein reiner Schnittstellenwandler. Vermutlich kommen auch deswegen die vielen 2Byte Telegramme > 0x80 am Anfang. Scheinen dann wohl Kollisionen zu sein. Am Service-Key wird man davon nichts mitbekommen. Gruß Ingo
Ich habe den ServiceKey-Bus mal analog gemessen und eine wav-Datei erstellt. Die kann man sich sehr leicht mit audacity etc. anschauen. Evtl. kann nochmal jemand rüber schauen ob es wirklich mit uart 8n1 9600 ausgelesen werden kann oder ob es dort noch versteckte bits (ack/nack) gibt.
Ich habe nochmal die Spec. vom Prozessor, bezüglich UART, gelesen und die Daten gesichtet. Der 8n1 9600 Mode ist okay. Das Nullbyte am Ende jeder Nachricht ist die Ende-Kennung bzw. ein UART Break Error. Es wird ein 0-Byte gesendet bei dem das Stopbit auf logisch 0 bleibt. Bei diesem Fehler wird vom Prozessor ein 0-Byte in den Bytestream eingefügt. Wird nach dem ersten Byte ein 0-Byte mit Stopbit 1 geschickt, folgen die Daten bis zum 0-Byte mit Stopbit 0. Die möglichen Transfermodis sehen also so aus: <ADDR> <0x00 (STOPBIT 1)> <DATA (STOPBIT 1)> <0x00 (STOPBIT 0)> <ADDR> <0x00 (STOPBIT 0)>
Update: <ADDR> <0x00 (STOPBIT 1)> <DATA (STOPBIT 1)> <0x00 (STOPBIT 0)> <ADDR> <0x00 (STOPBIT 0)> <ADDR> TIMEOUT
Anbei noch ein paar Frames die ich aus den analogen Daten extrahiert habe.
1 | 08 00 45 00 00 00 00 00 00 00 00 00 00 00 18 |
2 | 08 00 45 00 00 00 00 00 00 00 00 00 00 00 18 |
3 | 08 00 60 00 90 90 68 88 10 28 C0 80 5F |
4 | 08 00 60 00 90 90 68 88 30 68 C0 80 4B |
5 | 08 00 60 00 90 90 68 88 70 68 C0 80 43 |
6 | 08 00 60 00 90 90 68 88 90 A8 C0 80 6F |
7 | 08 00 60 00 90 90 68 88 B0 68 C0 80 5B |
8 | 08 00 60 00 90 90 68 88 D0 A8 C0 80 67 |
9 | 08 00 60 00 90 90 68 88 F0 E8 C0 80 73 |
10 | 08 00 7C 00 20 40 24 00 23 00 00 38 74 7C 00 00 26 88 E8 BD |
11 | 08 00 7C 00 20 40 24 00 23 00 00 38 74 7C 00 00 26 88 E8 BD |
12 | 08 00 7C 00 20 40 24 00 23 00 00 38 74 7C 00 00 26 88 E8 BD |
13 | 08 00 7C 00 20 40 24 00 23 00 00 38 74 7C 00 00 26 88 E8 BD |
14 | 08 00 7C 00 20 40 24 00 23 00 00 38 74 7C 00 00 26 88 E8 BD |
15 | 08 00 C5 00 70 80 80 A9 |
16 | 08 00 C5 00 70 80 80 A9 |
17 | 08 00 C5 00 70 80 80 A9 |
18 | 08 00 C5 00 70 80 80 A9 |
19 | 08 00 C5 00 70 80 80 A9 |
20 | 08 00 C5 00 70 80 80 A9 |
21 | 08 00 C5 00 70 80 80 A9 |
22 | 08 10 58 00 E8 26 26 00 16 |
23 | 08 10 58 00 E8 26 26 00 16 |
24 | 08 10 58 00 E8 26 26 00 16 |
25 | 08 10 58 00 E8 26 26 00 16 |
26 | 08 10 58 00 E8 26 26 00 16 |
27 | 08 10 58 00 E8 26 26 00 16 |
28 | 08 10 58 00 E8 26 26 00 16 |
29 | 08 10 AC 00 88 88 0C |
30 | 08 10 AC 00 88 88 0C |
31 | 08 10 AC 00 88 88 0C |
32 | 08 10 AC 00 88 88 0C |
33 | 08 10 AC 00 88 88 0C |
34 | 08 11 28 00 C0 76 |
35 | 08 11 28 00 C0 76 |
36 | 08 11 28 00 C0 76 |
37 | 08 11 28 00 C0 76 |
38 | 08 11 88 00 D8 46 |
39 | 08 11 88 0C 30 A8 |
40 | 08 11 88 18 D8 4A |
41 | 08 11 88 24 18 94 |
42 | 08 11 88 30 D8 5E |
43 | 10 00 18 00 E8 80 30 26 00 80 80 04 06 01 00 40 60 80 30 00 00 A8 0C 9A 00 33 00 00 00 28 |
44 | 10 00 18 00 E8 80 30 26 00 80 80 04 06 01 00 40 60 80 30 00 00 A8 0C 9A 00 33 00 00 00 28 |
45 | 10 00 18 00 E8 80 30 26 00 80 80 04 06 01 00 40 60 80 30 00 00 A8 0C 9A 00 33 00 00 00 28 |
46 | 10 00 18 00 E8 80 30 26 00 80 80 04 06 01 00 40 60 80 30 00 00 A8 0C 9A 00 33 00 00 00 28 |
47 | 10 00 18 00 E8 80 30 26 00 80 80 04 06 01 00 40 60 80 30 00 00 A8 0C 9A 00 33 00 00 00 28 |
48 | 10 00 18 00 E8 80 30 26 00 80 80 04 06 01 00 40 60 80 70 00 00 A8 0C 9A 00 33 00 00 00 3B |
49 | 10 00 18 00 E8 80 30 26 00 80 80 04 06 01 00 40 A0 80 30 00 00 A8 0C 9A 00 33 00 00 00 69 |
50 | 10 00 18 00 E8 80 30 26 00 80 80 04 06 01 00 40 A0 80 30 00 00 A8 0C 9A 00 33 00 00 00 69 |
51 | 10 00 18 00 E8 80 30 26 00 80 80 04 06 01 00 40 A0 80 30 00 00 A8 0C 9A 00 33 00 00 00 69 |
52 | 10 00 18 00 E8 80 30 26 00 80 80 04 06 01 00 40 A0 80 30 00 00 A8 0C 9A 00 33 00 00 00 69 |
53 | 10 00 18 00 E8 80 50 26 00 80 80 04 06 01 00 40 20 80 50 00 00 A8 0C 9A 00 33 00 00 00 75 |
54 | 10 00 18 00 E8 80 50 26 00 80 80 04 06 01 00 40 20 80 50 00 00 A8 0C 9A 00 33 00 00 00 75 |
55 | 10 00 18 00 E8 80 50 26 00 80 80 04 06 01 00 40 20 80 50 00 00 A8 0C 9A 00 33 00 00 00 75 |
56 | 10 00 18 00 E8 80 50 26 00 80 80 04 06 01 00 40 20 80 50 00 00 A8 0C 9A 00 33 00 00 00 75 |
57 | 10 00 18 00 E8 80 50 26 00 80 80 04 06 01 00 40 20 80 50 00 00 A8 0C 9A 00 33 00 00 00 75 |
58 | 10 00 18 00 E8 80 50 26 00 80 80 04 06 01 00 40 20 80 D0 00 00 A8 0C 9A 00 33 00 00 00 53 |
59 | 10 00 18 00 E8 80 50 26 00 80 80 04 06 01 00 40 20 80 D0 00 00 A8 0C 9A 00 33 00 00 00 53 |
60 | 10 00 18 00 E8 80 50 26 00 80 80 04 06 01 00 40 20 80 D0 00 00 A8 0C 9A 00 33 00 00 00 53 |
61 | 10 00 18 00 E8 80 50 26 00 80 80 04 06 01 00 40 20 80 D0 00 00 A8 0C 9A 00 33 00 00 00 53 |
62 | 10 00 18 00 E8 80 50 26 00 80 80 04 06 01 00 40 20 80 D0 00 00 A8 0C 9A 00 33 00 00 00 53 |
63 | 10 00 18 00 E8 80 50 26 00 80 80 04 06 01 00 40 20 80 D0 00 00 A8 0C 9A 00 33 00 00 00 53 |
64 | 10 00 18 00 E8 80 50 26 00 80 80 04 06 01 00 40 20 80 D0 00 00 A8 0C 9A 00 33 00 00 00 53 |
65 | 10 00 18 00 E8 80 50 26 00 80 80 04 06 01 00 40 20 80 D0 00 00 A8 0C 9A 00 33 00 00 00 53 |
66 | 10 00 18 00 E8 80 50 26 00 80 80 04 06 01 00 40 A0 80 D0 00 00 A8 0C 9A 00 33 00 00 00 C2 |
67 | 10 00 18 00 E8 80 D0 26 00 80 80 04 06 01 00 40 A0 80 30 00 00 A8 0C 9A 00 33 00 00 00 9D |
68 | 10 00 18 00 E8 80 D0 26 00 80 80 04 06 01 00 40 A0 80 30 00 00 A8 0C 9A 00 33 00 00 00 9D |
69 | 10 00 18 00 E8 80 D0 26 00 80 80 04 06 01 00 40 A0 80 30 00 00 A8 0C 9A 00 33 00 00 00 9D |
70 | 10 00 18 00 E8 80 D0 26 00 80 80 04 06 01 00 40 A0 80 30 00 00 A8 0C 9A 00 33 00 00 00 9D |
71 | 10 00 18 00 E8 80 D0 26 00 80 80 04 06 01 00 40 A0 80 D0 00 00 A8 0C 9A 00 33 00 00 00 39 |
72 | 10 00 18 00 E8 80 D0 26 00 80 80 04 06 01 00 40 A0 80 D0 00 00 A8 0C 9A 00 33 00 00 00 39 |
73 | 10 00 18 00 E8 80 D0 26 00 80 80 04 06 01 00 40 A0 80 D0 00 00 A8 0C 9A 00 33 00 00 00 39 |
74 | 10 00 18 00 E8 80 D0 26 00 80 80 04 06 01 00 40 A0 80 D0 00 00 A8 0C 9A 00 33 00 00 00 39 |
75 | 10 00 18 00 E8 80 D0 26 00 80 80 04 06 01 00 40 A0 80 D0 00 00 A8 0C 9A 00 33 00 00 00 39 |
76 | 10 00 18 00 E8 80 D0 26 00 80 80 04 06 01 00 40 A0 80 D0 00 00 A8 0C 9A 00 33 00 00 00 39 |
77 | 10 00 18 00 E8 80 D0 26 00 80 80 04 06 01 00 40 A0 80 D0 00 00 A8 0C 9A 00 33 00 00 00 39 |
78 | 10 00 18 00 E8 80 D0 26 00 80 80 04 06 01 00 40 A0 80 D0 00 00 A8 0C 9A 00 33 00 00 00 39 |
79 | 10 00 18 00 E8 80 D0 26 00 80 80 04 06 01 00 40 A0 80 D0 00 00 A8 0C 9A 00 33 00 00 00 39 |
80 | 10 00 18 00 E8 80 D0 26 00 80 80 04 06 01 00 40 A0 80 D0 00 00 A8 0C 9A 00 33 00 00 00 39 |
81 | 10 00 18 00 E8 80 D0 26 00 80 80 04 06 01 00 40 A0 80 D0 00 00 A8 0C 9A 00 33 00 00 00 39 |
82 | 10 00 2C 00 2C 40 20 40 20 84 00 00 C0 00 80 26 AC 00 30 64 00 A9 |
83 | 10 00 2C 00 2C 40 20 40 20 84 00 00 C0 00 80 26 AC 00 30 64 00 A9 |
84 | 10 00 2C 00 2C 40 20 40 20 84 00 00 C0 00 80 26 AC 00 30 64 00 A9 |
85 | 10 00 2C 00 2C 40 20 40 20 84 00 00 C0 00 80 26 AC 00 30 64 00 A9 |
86 | 10 00 2C 00 2C 40 20 40 20 84 00 00 C0 00 80 26 AC 00 30 64 00 A9 |
87 | 10 00 2C 00 2C 40 20 40 20 84 00 00 C0 00 80 26 AC 00 30 64 00 A9 |
88 | 10 00 2C 00 2C 40 20 40 20 84 00 00 C0 00 80 26 AC 00 30 64 00 A9 |
89 | 10 00 2C 00 2C 40 20 40 20 84 00 00 C0 00 80 26 AC 00 30 64 00 A9 |
90 | 10 00 2C 00 2C 40 20 40 20 84 00 00 C0 00 80 26 AC 00 30 64 00 A9 |
91 | 10 00 2C 00 2C 40 20 40 A0 84 00 00 C0 00 80 26 AC 00 30 64 00 38 |
92 | 10 00 2C 00 2C 40 20 40 A0 84 00 00 C0 00 80 26 AC 00 30 64 00 38 |
93 | 10 00 2C 00 2C 40 60 40 60 84 00 00 C0 00 80 26 AC 00 30 64 00 4D |
94 | 10 00 2C 00 2C 40 60 40 A0 84 00 00 C0 00 80 26 AC 00 30 64 00 0C |
95 | 10 00 2C 00 2C 40 60 40 A0 84 00 00 C0 00 80 26 AC 00 30 64 00 0C |
96 | 10 00 2C 00 2C 40 A0 40 60 84 00 00 C0 00 80 26 AC 00 30 64 00 11 |
97 | 10 00 2C 00 2C 40 A0 40 60 84 00 00 C0 00 80 26 AC 00 30 64 00 11 |
98 | 10 00 2C 00 2C 40 A0 40 60 84 00 00 C0 00 80 26 AC 00 30 64 00 11 |
99 | 10 00 2C 00 2C 40 A0 40 A0 84 00 00 C0 00 80 26 AC 00 30 64 00 50 |
100 | 10 00 2C 00 2C 40 A0 40 A0 84 00 00 C0 00 80 26 AC 00 30 64 00 50 |
101 | 10 00 2C 00 2C 40 A0 40 A0 84 00 00 C0 00 80 26 AC 00 30 64 00 50 |
102 | 10 00 2C 00 2C 40 A0 40 A0 84 00 00 C0 00 80 26 AC 00 30 64 00 50 |
103 | 10 00 2C 00 2C 40 A0 40 A0 84 00 00 C0 00 80 26 AC 00 30 64 00 50 |
104 | 10 00 2C 00 2C 40 A0 40 A0 84 00 00 C0 00 80 26 AC 00 30 64 00 50 |
105 | 10 00 2C 00 2C 40 A0 40 A0 84 00 00 C0 00 80 26 AC 00 30 64 00 50 |
106 | 10 00 2C 00 2C 40 A0 40 A0 84 00 00 C0 00 80 26 AC 00 30 64 00 50 |
107 | 10 00 2C 00 2C 40 A0 40 A0 84 00 00 C0 00 80 26 AC 00 30 64 00 50 |
108 | 10 00 2C 00 2C 40 A0 40 A0 84 00 00 C0 00 80 26 AC 00 30 64 00 50 |
109 | 10 00 2C 00 2C 40 A0 40 A0 84 00 00 C0 00 80 26 AC 00 30 64 00 50 |
110 | 10 00 2C 00 2C 40 A0 40 A0 84 00 00 C0 00 80 26 AC 00 30 64 00 50 |
111 | 10 00 2C 00 2C 40 A0 40 A0 84 00 00 C0 00 80 26 AC 00 30 64 00 50 |
112 | 10 00 2C 00 2C 40 A0 40 A0 84 00 00 C0 00 80 26 AC 00 30 64 00 50 |
113 | 10 00 2C 00 2C 40 A0 40 A0 84 00 00 C0 00 80 26 AC 00 30 64 00 50 |
114 | 10 00 2C 00 2C 40 A0 40 A0 84 00 00 C0 00 80 26 AC 00 30 64 00 50 |
115 | 10 00 2C 00 2C 40 A0 40 A0 84 00 00 C0 00 80 26 AC 00 30 64 00 50 |
116 | 10 00 2C 00 2C 40 A0 40 A0 84 00 00 C0 00 80 26 AC 00 30 64 00 50 |
117 | 10 00 2C 00 2C 40 A0 40 A0 84 00 00 C0 00 80 26 AC 00 30 64 00 50 |
118 | 10 00 2C 00 2C 40 A0 40 A0 84 00 00 C0 00 80 26 AC 00 30 64 00 50 |
119 | 10 00 2C 00 2C 40 A0 40 A0 84 00 00 C0 00 80 26 AC 00 30 64 00 50 |
120 | 10 00 2C 00 2C 40 A0 40 A0 84 00 00 C0 00 80 26 AC 00 30 64 00 50 |
121 | 10 00 98 00 00 5E 80 50 01 00 00 00 00 26 00 2D 94 90 67 BD 00 00 00 10 41 11 00 15 C0 00 |
122 | 10 00 98 00 00 5E 80 50 01 00 00 00 00 26 00 2D 94 90 67 BD 00 00 00 10 41 11 00 15 C0 00 |
123 | 10 00 98 00 00 5E 80 90 01 00 00 00 00 26 00 2D 94 90 67 BD 00 00 00 10 41 11 00 15 C0 3C |
124 | 10 00 98 00 00 5E 80 90 01 00 00 00 00 26 00 2D 94 90 67 BD 00 00 00 10 41 11 00 15 C0 3C |
125 | 10 00 98 00 00 5E 80 90 01 00 00 00 00 26 00 2D 94 90 67 BD 00 00 00 10 41 11 00 15 C0 3C |
126 | 10 00 98 00 00 5E 80 90 01 00 00 00 00 26 00 2D 94 90 67 BD 00 00 00 10 41 11 00 15 C0 3C |
127 | 10 00 98 00 00 5E 80 D0 01 00 00 00 00 26 00 2D 94 90 67 BD 00 00 00 10 41 11 00 15 C0 C7 |
128 | 10 00 98 00 00 DE 80 D0 01 00 00 00 00 26 00 2D 94 90 67 BD 00 00 00 10 41 11 00 15 C0 22 |
129 | 10 00 E0 00 C0 80 00 00 00 00 00 00 00 00 00 00 00 5B |
130 | 10 00 E0 00 C0 80 00 00 00 00 00 00 00 00 00 00 00 5B |
131 | 10 00 E0 00 C0 80 00 00 00 00 00 00 00 00 00 00 00 5B |
132 | 10 00 E0 00 C0 80 00 00 00 00 00 00 00 00 00 00 00 5B |
133 | 10 00 E0 00 C0 80 00 00 00 00 00 00 00 00 00 00 00 5B |
134 | 10 00 E0 00 C0 80 00 00 00 00 00 00 00 00 00 00 00 5B |
135 | 10 00 E0 00 C0 80 00 00 00 00 00 00 00 00 00 00 00 5B |
136 | 10 00 E0 00 C0 80 00 00 00 00 00 00 00 00 00 00 00 5B |
137 | 10 08 28 00 98 27 98 AF |
138 | 10 08 28 00 98 27 A8 9F |
139 | 10 08 28 00 98 27 D8 EF |
140 | 10 08 28 00 98 27 E8 DF |
141 | 10 08 88 00 4C 62 80 F0 91 90 08 D0 8C 00 00 00 9E |
142 | 10 08 88 0C 4C 62 80 F0 91 E0 50 08 E4 00 00 00 12 |
143 | 10 08 88 18 4C 62 80 F0 91 E0 D0 B8 E0 00 00 00 BC |
144 | 10 08 88 24 4C 62 80 F0 91 E0 88 88 6C 00 00 00 AB |
145 | 10 08 88 30 4C 62 80 F0 91 E0 30 78 80 00 00 00 C9 |
Update: <ADDR> <DATA (STOPBIT 1)> <0x00 (STOPBIT 0)> <ADDR> <0x00 (STOPBIT 0)> <ADDR> TIMEOUT
@Malte Bayer Meinst du die mit deinen Pins 3 & 4 die Pinne die ich auf dem Bild gekennzeichnet habe ??? Beitrag "Re: Logamatic 2107 Schnittstelle" Dort kommen Daten, dauert aber eine kleine Ewigkeit. Das sind die 50KHz die ich gemessen habe !
@Rudi, ja genau das Flachbandkabel meine ich. Du meinst aber Pins 23 und 24, der rote draht ist 1, nicht 26 ;) Auf dem Kabel gibt es noch TTL pegel Datenübertragung auf Pin 15 bis 18, die werde ich demnächst mal näher untersuchen, da ich momentan auch kein Material habe um das Differenzialsignal auszukoppeln. Ich bin sowieso ein TTL Mensch, bei 5V fühl ich mich wohl, kümmer du dich ruhig weiter um die anderen Signale, du hast da bestimmt viel mehr Ahnung von! :-) Im nachhinein bereue ich es glaube ich schon, dass ich so faul war und da ne Logamatic eingebaut habe - haette den Kessel ohne Steuerung bestellen sollen. Aber jetzt hat mich auch der Ehrgeiz gegriffen - das muss doch zu knacken sein. Auch wenn es total "unwirtschaftlich" ist, da Stunden an Zeit reinzuhauen, den Spass ist es mir wert, ausserdem lernt man ja nie aus, nich wahr? :-P Gruss & schoenes Wochenende, Malte
Hallo Malte, vielleicht kannst du mal nachmessen welche Pinne des Flackbandkabels auf die Pinne 1-10 und 1-20 der Relay Platine gehen die auf die Bus Platine geht (siehe mein Bild oben). Danke. Martin
> Aber jetzt hat mich auch der Ehrgeiz gegriffen - das muss doch zu > knacken sein. Auch wenn es total "unwirtschaftlich" ist, da Stunden an > Zeit reinzuhauen, den Spass ist es mir wert, ausserdem lernt man ja nie > aus, nich wahr? :-P Kommt drauf an was man mit den Daten anfängt. Mir geht es um die Kostenverteilung von Wasser und Heizung und dann per Holz die Heizkosten drücken. Da ich auch den Gaszähler angezapft habe, seh ich die Kosten mehr oder weniger direkt (der Gaszähler ist halt nur Mechanik). Ansonsten ist das schon etwas Arbeit die man dafür investieren muss. Wenn ich mir aber die Preise von diesem Zubehör anschaue dann hat es sich für mich bisher auf alle Fälle gelohnt. Geld und Lernfaktor.
@Malte Bayer > die werde ich demnächst mal näher untersuchen, da ich momentan auch kein > Material habe um das Differenzialsignal auszukoppeln. Kannst du mal ein paar Infos zu dem Signal posten ? Welche Pegel zu GND ? Bei mir hat das Signal auf dem EMS-Bus einen Offset von 12V +-2.5V Signal. Hast du dort evtl. 12V und die Signalleitung mit dem 12V Offset ?
@ Rudi: Pin 23 und 24 gegen GND im Ruhezustand +4,9V bei Datenübertragung fällt Spannung an beiden Pins zu unterschiedlichen Zeiten ab. Differenzspannung zwischen 23 und 24 bei Datenübertragung = +/- ca 3,8V Pulsabstand so wie ich das sehe ca 8 Mikrosekunden (bekomme ich nur mit der Hold on Trigger funktion halbwegs zu sehen). Also es ist doch nicht ganz das was du am Service key hast, gegen GND sind beide Leitungen entweder 4,9V oder irgendwas zwischen 0 und 1V. Wenn ich Pin23 als GND verwende und dann Pin24 messe bekomme ich Positive und negative Peaks, also bilden beide Leitungen zusammen eine AC Datenübertragung mit Pegel bei ca +/- 3,8V. @ Martin: Dein 1-10 und 1-20 ist exakt identisch mit Pin23 und Pin24 auf dem Flachbandkabel zwischen der Platine NM282 und dem Bedienpanel. (habe es mit dem Oszi verglichen, nicht mit durchgangsprüfer, so wahnsinnig bin ich dann doch nicht ;) @all: Die 2 TTL Signalübertragungen bringen mir bei allen Standardbaudraten über einen Max232 mit allen Kombinationen aus Stoppbits und parity nur müll an, scheinbar also keine asynchrone serielle Übertragung. (bin immer von 8bits ausgegangen). Update:
1 | 01 +5V - Versorgungsspannung? An der stelle steht ein "+" auf der Platine |
2 | 02 GND |
3 | 03 5V gemessen, vielleicht ein binärer E/A? |
4 | 04 5V gemessen, vielleicht ein binärer E/A? |
5 | 05 0V gemessen, vielleicht ein binärer E/A? |
6 | 06 0V gemessen, vielleicht ein binärer E/A? |
7 | 07 NC |
8 | 08 0V gemessen, vielleicht ein binärer E/A? |
9 | 09 Ausgang Heizkreis1 Pumpe (an=5V, aus=0V) |
10 | 10 0V gemessen, vielleicht ein binärer E/A? |
11 | 11 0V gemessen, vielleicht ein binärer E/A? |
12 | 12 0V gemessen, vielleicht ein binärer E/A? |
13 | 13 0V gemessen, vielleicht ein binärer E/A? |
14 | 14 0V gemessen, vielleicht ein binärer E/A? |
15 | 15 TTL Signal Low-Aktiv, feste Pulsbreite, unregelmässiges Signal, könnte Frame start interrupt sein |
16 | 16 TTL Signal variable Pulsbreite, sieht nach Datenübertragung aus |
17 | 17 TTL Signal variable Pulsbreite, sieht nach einem Enable Signal aus |
18 | 18 TTL Signal variable Pulsbreite, sieht nach einem Enable Signal aus |
19 | 19 5V gemessen, vielleicht ein binärer E/A? |
20 | 20 5V gemessen, vielleicht ein binärer E/A? |
21 | 21 0V gemessen, vielleicht ein binärer E/A? |
22 | 22 TTL Signal variable Pulsbreite, sieht nach Datenübertragung aus |
23 | 23 Datenübertragung Differential zu pin 24 |
24 | 24 Datenübertragung Differential zu pin 23 |
25 | 25 50hz sinus der fast wie dreieck aussieht 0,16V AC gemessen, ab und zu störungen messbar |
26 | 26 NC |
Hallo Rudi, >Ich habe den ServiceKey-Bus mal analog gemessen und eine wav-Datei >erstellt. Bei welcher Anlage/Steuerung hast Du die aufgezeichnet. >Anbei noch ein paar Frames die ich aus den analogen Daten extrahiert >habe. Na da warst Du aber Fleissig.... Oder hast Du da irgend ein Programm über die WAV-Datei laufen lassen die die Daten dekodiert hat? Denke da ist aber ein Fehler drin. Das LSB wird seriell als erstes übertragen. z.B. habe ich aus der Datei ein Telgrammanfang ermittelt der mit 08 00 18 00 97 01 0b 64... anfängt. Die Telegramme kann ich auch in meinem log auf dem COM-Port wiederfinden. Wenn ich dann LSB und MSB tausche komme ich auf ein Telegramm 10 00 18 00 E8 80 D0 26..... Habe dort auch dann beim letzten Byte eines Telegrammes das Stopbit 0 Seltsamerweise zeigt mein Programm auf der seriellen Schnittstelle keinen Fehler an obwohl das ja eigentlich ein Frameerror sein sollte. (HTerm 0.8.1) und würde auch gerne das über den Soundkarten Oszilloskop nachmessen. Aber irgendwie klappt das nicht. Hast Du noch irgend eine spezielle Schaltung gehabt um diese Datei aufzunehmen? Oder einfach nur mit der Soundkarte? Mein Laptop hat leider nur einen MIC-Eingang und kein Line-In Eingang. Dort konnte ich mit der Soundkarte kein vernünftiges Signal bekommen. nur kleine negative oder positive Hügelchen wenn das Signal von 0 auf 1 oder in die andere Richtung wechselt. Sollte man vielleicht vielleicht ein eigenen Thread für die 4000-Steuerung mit Service-Key aufmachen? Das hat ja eigentlich nichts mit der 2107 zu tun, oder? Gruß Ingo
@IngoF > Bei welcher Anlage/Steuerung hast Du die aufgezeichnet. Bei der aus dem Bild: Beitrag "Re: Logamatic 2107 Schnittstelle" > Oder hast Du da irgend ein Programm über die WAV-Datei laufen lassen die > die Daten dekodiert hat? Ich konvertiere das Signal vom Bus auf 3V3-Pegel (siehe Schaltung) und bin dann mit einem ADC an das Signal gegangen. Ich habe mit 300K-Samples aufgezeichnet. Leider sind die Daten nicht wirklich analog, es wird nur auf 1V5 getriggert, ansonsten hätte ich die Daten nicht auf den PC bekommen. Die Rohdaten habe ich dann in eine wav gewandelt und mir mit audacity angeschaut. Der Parser ist über die Rohdaten gegangen und nicht über die wav-Datei. > Denke da ist aber ein Fehler drin. Das LSB wird seriell als erstes > übertragen. z.B. habe ich aus der Datei ein Telgrammanfang ermittelt der Das würde wohl auch meine glücklosen Versuche, die CRC zu berechnen, erklären. > Seltsamerweise zeigt mein Programm auf der seriellen Schnittstelle > keinen Fehler an obwohl das ja eigentlich ein Frameerror sein sollte. > (HTerm 0.8.1) und würde auch gerne das über den Soundkarten Oszilloskop > nachmessen. Aber irgendwie klappt das nicht. Ich habe mal andere Sachen mit dem Soundkarten Oszi gemessen, ging ganz gut wenn 48KHz ausreiched sind. Dieser Break-Fehler ist ja mehr oder weniger Hardwareabhängig. > Dort konnte ich mit der Soundkarte kein vernünftiges Signal bekommen. > nur kleine negative oder positive Hügelchen wenn das Signal von 0 auf 1 > oder in die andere Richtung wechselt. Das Signal kannst du so nicht messen, da es sich um ein DC-Signal handelt. Hinter dem Eingang kommt direkt ein Kondensator der nur den AC-Anteil an die Soundkarte weiterleitet. Ich habe mit einem cortex gemessen und dann über Netzwerk die Daten übertragen. Leider hat das Biest keine DMA und aus diesem Grund konnte ich keine echten Analog-Werte sampeln, da es die CPU nicht mehr geschafft hat die Daten zu übertragen. > Sollte man vielleicht vielleicht ein eigenen Thread für die > 4000-Steuerung mit Service-Key aufmachen? Das hat ja eigentlich nichts > mit der 2107 zu tun, oder? Warten wir erstmal ab was bei der 2107 am Bus anliegt.
@Malte Bayer > Pin 23 und 24 gegen GND im Ruhezustand +4,9V bei Datenübertragung fällt > Spannung an beiden Pins zu unterschiedlichen Zeiten ab. > Differenzspannung zwischen 23 und 24 bei Datenübertragung = +/- ca 3,8V > Pulsabstand so wie ich das sehe ca 8 Mikrosekunden (bekomme ich nur mit > der Hold on Trigger funktion halbwegs zu sehen). Ich hatte damals diese beiden ganz gut messen können (zu GND). Wie schon gesagt habe ich dort die 50KHz Signal gemessen (20uS). Ich hoffe nächste Woche ist das Kabel bei der Heizung und dann kann ich das mal aufnehmen.
Angehängte Dateien:
-
hterm081.PNG
28 KB -
FIFO_Int.PNG
7,4 KB
Hallo Rudi, Also mit den Frameerror habe ich inzwischen nachvollziehen können. Dazu habe ich HTerm genommen und 9600 8N1 eingestellt. Am PC musste ich dann noch am FIFO-Interupt Trigger Level den Wert auf 1 stellen, damit nach jedem Byte ein Interrupt erzeugt wird. Wenn der Wert nicht verstellt wird gibt es nur Overflow-Errors. Die Roten Werte sind also dann nur noch die Frameerror. Wenn mehrere Werte hintereinander rot gekennzeichnet sind liegt dass daran dass die Werte zusammen mit einem 00-Byte mit Frameerror empfangen wurden. Also ist nicht alles Rote auch wirklich ein Frameerroe. Soweit ich sehen kann werden die Frameerrors nur erzeugt wenn Nach der Adresse keine Daten mehr kommen. man kann zwei 08-Telegramme sehen die hintereinander folgen. Hier kann man sehen (Statusleiste unten)dass dort ein Abstand von etwa 170ms kommt. >Leider sind die Daten nicht wirklich analog, es wird nur >auf 1V5 getriggert, ansonsten hätte ich die Daten nicht auf den PC >bekommen. Na das erklärt die super sauberen Flanken und absolut keine Störungen... Habe mich auch schon gewundert warum bei 100KHz-Samplingrate (laut Dateiinfo 100kHz/16Bit) dann nur die Übertragungsrate zwischen bei etwa 3600 Bit/s lag. Habe dann zum Spass mal zurückgerechnet und bin rechnerisch auf 278kHz gekommen. Hab sowas schon vermutet dass ein Kondensator der Übeltäter ist. Hatte dann vermutet dass der Line-In vielleicht nicht so einen Kondendator hat und es dann damit geklappt hätte. Gruß Ingo
P.S.: noch vergessen: Die Zeit wird zwischen den beiden blau hervorgehobenen Bytes gemessen Am Anfang kommt nach allen zwei Bytes ein Frameerror nach einiger Zeit kommen nach auf einmal viel weniger Frameerrors. Vielleicht liegt das an Windows (Programmpriorität?) Wenn das also alles so stimmt wie es dort angezeigt wird kommen die 00 mit Frameerror direkt nach der Adresse wenn keine weiteren Daten gesendet werden. Alles was über >=0x80 ist könnte vielleicht eine Art Statusänderungen sein oder vielleicht Kollisionen. Aber in Deiner WAV-Datei sieht es eher so aus als ob das keine Kollisionen sind... Oder liege ich da falsch? Gruß Ingp
Hallo, @Malte: kannst du mal ein Bild von dem differentiellen Signal hier einstellen (Zur Not Bild vom OsziSchirm)? Danke. Martin
@IngoF > Soweit ich sehen kann werden die Frameerrors nur erzeugt wenn Nach der > Adresse keine Daten mehr kommen. Ja genau, siehe hier: Beitrag "Re: Logamatic 2107 Schnittstelle" Es gibt auch Adressen mit keiner 0. Das habe ich erstmal Timeout genannt, danach wird sehr lange (relativ) nichts auf dem Bus gesendet. > Na das erklärt die super sauberen Flanken und absolut keine Störungen... > Habe mich auch schon gewundert warum bei 100KHz-Samplingrate (laut > Dateiinfo 100kHz/16Bit) ;-) Beim Import habe ich zwar 300KHz angegeben, aber audacity hat es nach dem Import auf 100KHz gestellt. Scheint ein Bug zu sein. > Die Roten Werte sind also dann nur noch die Frameerror. Wenn mehrere > Werte hintereinander rot gekennzeichnet sind liegt dass daran dass die > Werte zusammen mit einem 00-Byte mit Frameerror empfangen wurden. Also > ist nicht alles Rote auch wirklich ein Frameerroe. Das liegt nur am FIFO. Habe ich im Datenblatt zum cortex auch gelesen. Es wird nur angeben das bei den Daten im FIFO ein Fehler aufgetreten ist, aber nicht bei welchem Byte. > Am Anfang kommt nach allen zwei Bytes ein Frameerror nach einiger Zeit > kommen nach auf einmal viel weniger Frameerrors. Vielleicht liegt das an > Windows (Programmpriorität?) Das kann ich dir nun nicht erklären, aber die Frameerrors sind definitiv auf dem Bus. Hast du schon Daten gesehen bei denen an zweiter Stelle keine 0 steht, wie bei meinen "falschen" Daten weiter oben (alle Bits gedreht) ? Die Adressen auf dem Bus zeigt dir die Anlage im Service Menu. Ich muss selbst nochmal schauen welche Adressen bei mir auf dem Bus liegen, es waren glaube ich 4 Geräte.
Laut Servicemenü: 0x08 UBA3/MC10 0x09 BC10 0x10 RC30 Eigentlich habe ich bisher noch keine Daten gesehen bei der nach der Adresse keine 00 kommt. Allerdings habe ich auch kein Programm was mir die Arbeit abnimmt und die Daten oder telegramme decodiert. Vielleicht sollte ich mich mal ein daran machen... >Es gibt auch Adressen mit keiner 0. Das habe ich erstmal Timeout >genannt, danach wird sehr lange (relativ) nichts auf dem Bus gesendet. ja, die waren aber immer >=80 (Bit7 gesetzt) vielleicht ist das ja irgend ein Status von irgendwelchen Anlagenteilen.
> Eigentlich habe ich bisher noch keine Daten gesehen bei der nach der > Adresse keine 00 kommt. Allerdings habe ich auch kein Programm was mir > die Arbeit abnimmt und die Daten oder telegramme decodiert. Wenn du auf deinem Rechner python installieren kannst, dann könnte ich dir ein paar Programmteile für die Kommunikation zukommen lassen. Da wir jetzt mehr oder weniger die Daten kennen, bräuchte man nicht unbedingt auf den Frame-Error achten. Wenn du dich für python entscheidest, dann brauchst du noch pyserial für die Kommunikation. Mit python ist es erstmal easy going ...
Angehängte Dateien:
-
hterm081.PNG
25 KB
Habe es inzwischen hinbekommen wie man sieht werden alle Telegramme mit einer 00 mit Stopbit 0 beendet. Der Bildschirmaufbau hat die Ergebnisse verfälscht. Wenn mann das Fenster so stark verkleinert dass nur noch die Schaltflächen [Clear received] und [Connect] werden die korrekten Werte angezeigt. nach jedem 08 00 kommt ein Zeilenumbruch. Jetzt kann man schon viel besser die Telegramme finden... Gruß Ingo
Das sieht doch schon gut aus. Ich sehe da auch 10 00. Das würde die Theorie mit dem Status etwas über den Haufen werden. Ich behaupte einfach mal das der Bus ganz stumpf gepollt wird. Wenn ein Gerät etwas zu sagen hat dann antwortet es, ansonsten nicht.
Also ich sehe hier Timeouts bei Adresse 0x11,0x18 und 0x19. Ich habe mal die ADC-Daten und den Parser angehängt. Der Parser is in python geschrieben. Dort werden die Bits ausgewertet und dann auf UART-Protokoll auf 8n1 gewandelt. Du kannst die Timeouts sehen, und den Rest der Daten. Daten mit nur einem Byte (<ADDR> <0x00>) werden nicht angezeigt. Die ADC-Daten sehen wie folgt aus. Ein Wert besteht aus 2 Bytes. Das erste Byte ist die Anzahl und das zweite Byte ist der Pegel (0/1).
Im Script muss der Namen der Datei von 12345 auf data_adc.bin geändernt
werden ...
f = open("12345","r");
=>
f = open("data_adc.bin","r");
@Rudi: Also bei mir kommt nachdem ich "12345" durch den Dateinamen ersetzt habe und das "Import Serial" gelöscht habe nur folgende Ausgabe:
1 | out |
2 | 11 timeout 2252 |
3 | 11 timeout 2252 |
4 | 19 timeout 2201 |
Wenn ich den Import nicht lösche wird rumgemeckert dass kein Modul Serial eristiert. Habe irgendwo pyserial gefunden und versucht zu installieren. meckert dann aber dass er win32file nicht findet..... Wusste nicht dass bei Windows XP schon automatisch Phyton mitgeliefert wird... Habe vorher eigentlich noch nie was von Phyton gehört...
Evtl. hat ein Programm python installiert. Mit Windows wird es meines Wissens nicht mitgeliefert. Das Modul serial ist nur für die serielle Kommunikation gedacht. Ich habe es hier mit python 2.5 und 2.6 getestet und es funktioniert. Die Ausgabe sieht wie folgt aus:
1 | out
|
2 | 11 timeout 2252 |
3 | 11 timeout 2252 |
4 | 19 timeout 2201 |
5 | 10 00 2C 00 2C 40 20 40 A0 84 00 00 C0 00 80 26 AC 00 30 64 00 38 |
6 | 10 00 18 00 E8 80 50 26 00 80 80 04 06 01 00 40 20 80 D0 00 00 A8 0C 9A 00 33 00 00 00 53 |
7 | 19 timeout 2251 |
8 | 19 timeout 2251 |
9 | 19 timeout 2252 |
10 | 19 timeout 2251 |
11 | 10 00 98 00 00 5E 80 90 01 00 00 00 00 26 00 2D 94 90 67 BD 00 00 00 10 41 11 00 15 C0 3C |
12 | 10 00 2C 00 2C 40 20 40 20 84 00 00 C0 00 80 26 AC 00 30 64 00 A9 |
13 | 10 00 E0 00 C0 80 00 00 00 00 00 00 00 00 00 00 00 5B |
14 | 10 00 18 00 E8 80 50 26 00 80 80 04 06 01 00 40 20 80 D0 00 00 A8 0C 9A 00 33 00 00 00 53 |
15 | 11 timeout 2252 |
16 | 19 timeout 2151 |
17 | 11 timeout 2254 |
18 | 19 timeout 2153 |
19 | 19 timeout 2201 |
20 | 18 timeout 2251 |
21 | 10 00 2C 00 2C 40 20 40 20 84 00 00 C0 00 80 26 AC 00 30 64 00 A9 |
22 | 10 00 18 00 E8 80 50 26 00 80 80 04 06 01 00 40 20 80 D0 00 00 A8 0C 9A 00 33 00 00 00 53 |
23 | 11 timeout 2254 |
24 | 11 timeout 2254 |
25 | 08 00 C5 00 70 80 80 A9 |
26 | 08 10 58 00 E8 26 26 00 16 |
27 | 11 timeout 2252 |
28 | 10 00 2C 00 2C 40 20 40 20 84 00 00 C0 00 80 26 AC 00 30 64 00 A9 |
29 | 10 00 18 00 E8 80 50 26 00 80 80 04 06 01 00 40 20 80 D0 00 00 A8 0C 9A 00 33 00 00 00 53 |
30 | 08 00 60 00 90 90 68 88 70 68 C0 80 43 |
31 | 19 timeout 2251 |
32 | 19 timeout 2251 |
33 | 19 timeout 2251 |
34 | 10 00 2C 00 2C 40 20 40 20 84 00 00 C0 00 80 26 AC 00 30 64 00 A9 |
35 | 19 timeout 2220 |
36 | 10 00 18 00 E8 80 50 26 00 80 80 04 06 01 00 40 20 80 50 00 00 A8 0C 9A 00 33 00 00 00 75 |
37 | 08 00 7C 00 20 40 24 00 23 00 00 38 74 7C 00 00 26 88 E8 BD |
38 | 08 10 AC 00 88 88 0C |
39 | 18 timeout 2201 |
40 | 10 00 2C 00 2C 40 20 40 20 84 00 00 C0 00 80 26 AC 00 30 64 00 A9 |
41 | 10 00 18 00 E8 80 50 26 00 80 80 04 06 01 00 40 20 80 50 00 00 A8 0C 9A 00 33 00 00 00 75 |
42 | 11 timeout 2252 |
43 | 19 timeout 2151 |
44 | 19 timeout 2154 |
45 | 19 timeout 2202 |
46 | 19 timeout 2202 |
47 | 18 timeout 2200 |
48 | 19 timeout 2251 |
49 | 10 00 2C 00 2C 40 20 40 20 84 00 00 C0 00 80 26 AC 00 30 64 00 A9 |
50 | 10 00 18 00 E8 80 50 26 00 80 80 04 06 01 00 40 20 80 50 00 00 A8 0C 9A 00 33 00 00 00 75 |
51 | 19 timeout 2152 |
52 | 19 timeout 2251 |
53 | 18 timeout 2201 |
54 | 19 timeout 2253 |
55 | 19 timeout 2253 |
56 | 10 00 98 00 00 5E 80 90 01 00 00 00 00 26 00 2D 94 90 67 BD 00 00 00 10 41 11 00 15 C0 3C |
57 | 10 00 2C 00 2C 40 20 40 20 84 00 00 C0 00 80 26 AC 00 30 64 00 A9 |
58 | 10 00 E0 00 C0 80 00 00 00 00 00 00 00 00 00 00 00 5B |
59 | 10 00 18 00 E8 80 50 26 00 80 80 04 06 01 00 40 20 80 50 00 00 A8 0C 9A 00 33 00 00 00 75 |
60 | 19 timeout 2152 |
61 | 08 00 45 00 00 00 00 00 00 00 00 00 00 00 18 |
62 | 11 timeout 2201 |
63 | 19 timeout 2201 |
64 | 10 00 2C 00 2C 40 20 40 20 84 00 00 C0 00 80 26 AC 00 30 64 00 A9 |
65 | 19 timeout 2273 |
66 | 10 00 18 00 E8 80 50 26 00 80 80 04 06 01 00 40 20 80 D0 00 00 A8 0C 9A 00 33 00 00 00 53 |
67 | 18 timeout 2202 |
68 | 19 timeout 2154 |
69 | 19 timeout 2202 |
70 | 08 00 C5 00 70 80 80 A9 |
71 | 08 10 58 00 E8 26 26 00 16 |
72 | 08 11 28 00 C0 76 |
73 | 10 08 28 00 98 27 D8 EF |
74 | 10 00 2C 00 2C 40 20 40 20 84 00 00 C0 00 80 26 AC 00 30 64 00 A9 |
75 | 10 00 18 00 E8 80 50 26 00 80 80 04 06 01 00 40 20 80 50 00 00 A8 0C 9A 00 33 00 00 00 75 |
76 | 19 timeout 2201 |
77 | 08 00 60 00 90 90 68 88 F0 E8 C0 80 73 |
78 | 19 timeout 2154 |
79 | 19 timeout 2203 |
80 | 18 timeout 2251 |
Info zur Logomatic 2107 und Post Beitrag "Re: Logamatic 2107 Schnittstelle" Sockel K4 PIN 3,4,5,6 Gehen zum KM 271 RS232 Interface. Siehe hier: Beitrag "Re: Buderus Ecomatic 4000" Hier nochmal ein Aufruf: ------------------------ Falls jemand im Besitz der KM 271 Platine ist, würden wir uns sehr über hochauflösende Bilder von beiden Seiten freuen (Aufkleber bitte vorher entfernen) ! Danke!
@IngoF Könnten die Daten evlt. als 9n1 geschickt werden ? Ich habe mir das Timing jetzt nicht angeschaut (ob das Stopbit dann noch passt), aber dann bräuchte man nicht über diesen Frame-Error Fehler gehen, sondern könnte direkt in den 9 Bit das Ende erkennen ???
Nein, Das war ja auch mein erster Gedanke. Aber es werden 10Bit übertragen. (1 Startbit + 8Datenbit + 1 Stopbit). Und es gibt keine Möglichkeit wie 1 Startbit + 8 Datenbit + 1 Parity Mark + 0 Stopbit. Das Parity-Bit wird außerdem genauso ausgewertet wie der Frameerror. Es gibt auch nur 5-8 Bit Datenübertagung, 9 Bit ist nicht möglich. Werde mich mal an ein JAVA-Testprogramm machen...
Zur 2107 Die Leitungen: 23 Datenübertragung Differential zu pin 24 24 Datenübertragung Differential zu pin 23 sind gegen GND jeweils eine Datenleitung und eine Clockleitung. Ich konnte heute Messungen aufnehmen und Oszi-Bilder machen. Diese beiden Signale tauchen auch auf K4 (für das RS232-Interface) auf. Die CLK ist etwa 44KHz und es werden (auf den ersten Blick) 9 oder 10 Bits verschickt.
Angehängte Dateien:
-
090925_191434.jpg
120 KB -
090925_191957.jpg
110 KB -
090925_192147.jpg
200 KB -
090925_192226.jpg
110 KB
Moin, anbei die ersten Bilder ...
Anbei eine Log-Datei. Ohne Clock etwas schwer zu dekodieren, aber die Daten sehen schonmal vielversprechend aus.
Hallo Rudi, seeeeeehr gut! Sehe ich das richtig? Gültige Daten bei fallender Flanke? Wie hast du das .wav File aufgenommen? Evtl. Spanungsteiler vor eine Soundkarte und dann linke Kanal Takt und rechter Kanal Daten. Oder einen Mikrocontroller der bei fallender Flanke guckt was an DatenPin anliegt und dann eine 0 oder 1 seriell rausschreibt. Das ganze dann eine Zeitlang aufzeichnen. Meistens "sieht" man dann die logischen Blöcke schon in Hyperterminal oder einem anderen Terminalprogramm. Kommen denn ständig Daten oder ist da auch eine "längere" Pause zwischen Blöcken? Martin
> Wie hast du das .wav File aufgenommen? Evtl. Spanungsteiler vor eine > Soundkarte und dann linke Kanal Takt und rechter Kanal Daten. Die Soundkarte ist zu langsam und kann nur analoge Daten aufnehmen. Die Schaltung siehe oben und dann per ADC augenommen, der ADC ist aber zu langsam wie man bei einigen Daten sieht. > Oder einen Mikrocontroller der bei fallender Flanke guckt was an > DatenPin anliegt und dann eine 0 oder 1 seriell rausschreibt. Das ganze > dann eine Zeitlang aufzeichnen. Meistens "sieht" man dann die logischen > Blöcke schon in Hyperterminal oder einem anderen Terminalprogramm. So will ich es nochmal versuchen, bei einer Bitrate von 44KHz sollten die Daten problemlos über eine 115KBaud serielle mit FIFO gehen. Dann ist die CLK wenigstens direkt mit bei. Zwischen den "Blöcken" ist eine längere Pause und wie man in der wav-Datei sieht, kommen die Daten kontinuierlich.
Hallo Rudi, ich befürchte nur, da es sich um eine synchrone Übertragung handelt, sich der Dateineingang noch auf einem anderen Pin befindet als der Ausgang. Aber sicherlich auf einem der wieder nur auf K4 anliegt.... Martin
> ich befürchte nur, da es sich um eine synchrone Übertragung handelt, > sich der Dateineingang noch auf einem anderen Pin befindet als der > Ausgang. > Aber sicherlich auf einem der wieder nur auf K4 anliegt.... Wenn es sich um einen Bus handelt, dann ist IN==OUT. Evtl. gibt es noch ein BUS-Select o.ä.. Wenn der Input nicht an alle Teilnehmer geleitet wird, dann könnte man den auch gleich weglassen.
Hi! Ja, sieht echt verdammt nach einer synchronen Übertragung aus. Ich versuche in den nächsten Wochen mal, so ein RS232 Modul beim Heizungstechniker meines Vertrauens für ein paar Tage auszuleihen. Vielleicht reicht auch ein Blick auf ne andere Buderus Steuerung bei nem Kumpel (der hat ein RS232 Modul drin, ist keine Logamatic, aber vielleicht identisches Modul - man weiss ja nie). Melde mich wieder, wenn ich erkenntnisse habe! Gruss, Malte
@IngoF Hast du schon die Vor- und Rücklauftemperatur für die Heizkreise ermitteln können ?
Hallo, Nein, habe bisher noch nichts herausfinden können.. Hatte leider nicht allzuviel Zeit. Habe ein Programm in Java geschrieben um die Daten mitzuloggen. Allerdings scheint das Programm bisher zu lahm zu sein. Die Erfolgsrate bei der Erkennung des Break-Interrupt liegt noch bei 30% Aber habe noch eine Idee wie ich das vielleicht ändern könnte... Gruß Ingo
Hi, ich habe nochmal geschaut, da die Heizung langsam wieder anspringt. Die Vorlauftemperatur habe ich gefunden, auch den Betriebsstundenzähler und einige andere Temperaturen. Ich werde mal alle gefunden Nachrichten sammeln und dann mit dem Serviceheft (Anzeige Servicemenue) verlgleichen und hier posten. Ich bin grad am überlegen ob ich den Levelkonverter direkt mit einer CPU, die wenigstens 2 UARTs hat, verheirate und dann an meinen Netzwerkkontroller gehe. Ich wollte eigentlich nicht 100% CPU-Last für die Break-Erkennung investieren. Ich hätte einen mega644p der 2 UARTs hat und den Schweinkram erledigen kann ;-) Was hast du dir gedacht ? Grüße.
Also hab es noch mal ausprobiert. Die Break-Interupt Auswertung mit Java ist unmöglich. Ist eben einfach viiiiieeeeeel zu langsam dafür. Selbst wenn ich GUI weglasse und nur die Anzahl der Bytes vor dem letzten Break ausgebe haut das nicht hin. Hatte auch schon den Gedanken. Allerdings hatte ich da an einen PIC gedacht. Aber das macht wohl hier keiner. Ich würde evtl. noch niemals einen UART für die Auswertung nehmen, nur zum senden zum PC (mit mehr Dampf als die 9600Bit/s.) Als Option würde sich der STI101 anbieten (USB-Stick Interface mit RS232/I2C) wenn man keinen Server hat oder haben möchte. Ich würde aus den 12V +- 2,5V die Speisung notfalls mit einen 7805 herstellen. An dem BUS-Abgriff würde ich vorschlagen einen simplen Spannungsteiler zu nehmen und dann mit einem CMOS-Schmitt-Trigger das Signal auf den Controller zur Auswertung geben. OP würde auch gehen. Vielleicht noch eine galvanische Trennung mit Optokoppler oder ähnlichem an der RS232 zum PC. Vielleicht könnte ich mich auch mit einem AVR anfreunden. Allerdings dann mit Assembler weil ich kein C programmieren kann und es schneller ist. Allerdings bräuchte ich dann die komplette Entwicklungsumgebung inkl. Controller. Als Simulator müsste auch AVR-Studio gehen, oder gibt es was besseres dafür? Gruß Ingo
>und dann an meinen Netzwerkkontroller gehe.
habe ich glatt überlesen? Wie hast Du Dir dass denn vorgestellt? Wäre
natürlich super eine Verbindung über Netzwerk z.B. auf eine Festplatte
zu loggen. Aber vermutlich hast Du Dir noch eine Software auf dem Server
vorgestellt die dass übernimmt, oder?
Dann wäre man wieder beim "Server-Problem" wollte eigentlich keinen
Rechner nur für die Heizung mitlaufen lassen.
Gruß
Ingo
Hi, schau dir mal den ADCMP370 an. Als Empfänger ist der soweit okay (läuft hier bereits). Zwecks Abgriff der 12V als Stromversorgung: ich habe keinen Plan was man dort abzapfen kann, aus diesem Grund möchte ich in diese Richtung auch nicht weiterdenken. Vor dem ADCMP370 ein Opto wäre okay, wenn es überhaupt möglicht ist, wäre aber auch mein Wunsch. Damit das nicht eine eierlgende Wollmichsau wird würde ich folgendes vorschlagen: HEIZUNG <-> MODUL OPTO <-> MODUL WANDLER <-> MODUL SKLAVE <-> MODUL KNECHT <-> MODUL AUSWERTUNG Module: OPTO : galvanische Trennung WANDLER : level shifter SKLAVE : Erkennung der Nachrichten (anhand des Breaks und Aufbereitung der Daten) KNECHT : Empfang der Daten vom Sklaven und redundanz Check bzw. Empfang von anderen (nicht CPU lastigen) Sensordaten AUSWERTUNG: wie immer man das auch machen möchte Ich habe das Modul: WANDLER (ADCMP370) , KNECHT cortex (geht noch über die Zeit, siehe andere Postings) / Laptop (Empfang der Daten vom KNECHT und Weiterleitung per WLAN an Modul AUSWERTUNG) und AUSWERTUNG (SERVER) Web-Interface/Datenbank OPTO und WANDLER sind wohl erstmal Notlösungen oder nicht vorhanden. Für den SKLAVEN kann ich mir eine einfache CPU vorstellen (PIC,AVR nur einfach mit einer UART-BREAK-Erkennung und einer Schnittstelle zur Anbindung an den KNECHT (UART/SPI/usw. (I2C ist zu CPU-lastig)). Das Modul SKLAVE hat nur die Aufgabe der Break-Erkennung und der Weiterleitung. Der KNECHT wird bei mir ein M3 mit Netzwerk und SD-Karte sein. Der sendet die Daten an meinen Server, der die Daten auswertet/visualisiert. Wenn der Server nicht erreichbar ist werden die Daten auf SD-Karte gespeichert und später verschickt. So sieht mein Plan aus. Meine für die Zukunft vorhandenen Module: OPTO --- nicht vorhanden WANDLER (ADCMP370) --- läuft SKLAVE (evtl. avr644p) --- in Gebrauch, für Aufgabe diese ungetestet KNECHT (cortex LM3S8938) --- Prototyp läuft, für diese Aufgabe ungetestet AUSWERTUNG (server) --- läuft
Hallo Rudi, kannst Du die erkannten Werte zum Vergleich mal posten (siehe meine Nachricht vom 16.9.09)? Danke, Mario
Angehängte Dateien:
-
Unbenannt.png
13 KB
1 | # 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29
|
2 | # 08 10 14 00 1A 2C 8B E2 00
|
3 | if ord(data[0]) == 0x08 and ord(data[1]) == 0x10 and ord(data[2]) == 0x14: |
4 | t1 = (ord(data[4])<<16) | (ord(data[5])<<8) | ord(data[6]) |
5 | t1 = t1 / 60 |
6 | print "Betriebsstunden:",t1 |
Die Minuten müssen dann noch nach 60 umgerechnet werden ...
1 | # 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29
|
2 | # 08 00 18 00 22 01 31 64 00 01 01 20 60 80 00 01 D8 01 32 00 00 15 30 59 00 CC 00 00 00 77
|
3 | |
4 | if ord(data[0]) == 0x08 and ord(data[2]) == 0x18: |
5 | t1 = ((ord(data[5])<<8)|ord(data[6]))/10.0 |
6 | data_container.D_DB_TEMP_KESSEL = change_value( D_DB_TEMP_KESSEL , data_container.D_DB_TEMP_KESSEL, t1 ) |
7 | t2 = ord(data[11]) |
8 | data_container.D_DB_CIRC = change_value( D_DB_CIRC , data_container.D_DB_CIRC, t2 ) |
9 | t3 = ord(data[21])/10.0 |
10 | data_container.D_DB_BAR = change_value( D_DB_BAR , data_container.D_DB_BAR, t3 ) |
11 | t4 = ((ord(data[15])<<8)|ord(data[16]))/10.0 |
12 | data_container.D_DB_TEMP_U1 = change_value( D_DB_TEMP_U1 , data_container.D_DB_TEMP_U1, t4 ) |
13 | t5 = ((ord(data[17])<<8)|ord(data[18]))/10.0 |
14 | data_container.D_DB_TEMP_U2 = change_value( D_DB_TEMP_U2 , data_container.D_DB_TEMP_U2, t5 ) |
15 | # HK1 Vorlauf
|
16 | t6 = ord(data[4])*1.0 |
17 | data_container.D_DB_TEMP_HK1_VL = change_value( D_DB_TEMP_HK1_VL , data_container.D_DB_TEMP_HK1_VL, t6 ) |
Dort sind 3 neue Temperaturen, 2 unbekannte, sind offensichtlich Mittelwerter o.s.ä..
1 | # 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29
|
2 | # 08 00 19 00 00 7D 01 31 80 00 00 00 00 64 00 B4 9A 09 E9 CE 00 00 00 08 82 A0 00 A8 43 16 00
|
3 | if ord(data[0]) == 0x08 and ord(data[2]) == 0x19: |
4 | t1 = ((ord(data[4])<<8)|ord(data[5]))/10.0 |
5 | t2 = ((ord(data[6])<<8)|ord(data[7]))/10.0 |
6 | # brenner starts
|
7 | t3 = ((ord(data[15])<<8)|ord(data[16])) |
8 | |
9 | data_container.D_DB_TEMP_AUSSEN = change_value( D_DB_TEMP_AUSSEN , data_container.D_DB_TEMP_AUSSEN, t1 ) |
10 | data_container.D_DB_TEMP_U3 = change_value( D_DB_TEMP_U3 , data_container.D_DB_TEMP_U3, t2 ) |
Hier die Brennerstarts (evtl. 3 bytes) und eine neue Temp. Die unbekannten Temperaturen sind wohl alles Mittelwerte. Z.Z. geht es langsam los mit der Heizung (siehe Bild).
Hallo Rudi, Habe mich mal ein wenig über die Komponenten informiert. Hört sich ja alles sehr gut an. Vielleicht sollte man noch einen kleineren "sklaven" nehmen... Der avr644p hat, wenn ich da richtig liege, 40 Pins. da müsste doch ein ATtiny2313 oder ähnliches reichen, oder? Kann mann den Cortex M3 auch über den USBprog programmieren, oder wie programmierst Du den. Hast Du bis jetzt eine selbstentwickelte Schaltung oder eine eingekaufte? Also wenn ich was helfen kann, dann bin ich dabei... Gruß Ingo
Würde den Sklaven inkl. Wandler am liebsten auf eine eigene Platine packen oder zumindest einen Steckplatz dafür vorsehen. Dann kann man evtl hinterher noch die Platine gegen eine Sende/Empfangsplatine austauschen falls es irgendwann mal oweit sein könnte. Ein Steckplatz für ein einfache 2 oder 4 zeiliges LCD-Display mit Controller könnte man auch einplanen. Da würden doch bestimmt ein paar Pins für freibleiben. Außerdem könnte man dann noch ein paar Platinen mehr machen und vür andere Funktionen gebrauchen. Hätte bestimmt ein paar Anschlussprojekte... Womit hast Du denn die Platinen geroutet? Die Auswertung würde ich dann aber vermutlich hinterher noch in dem Cortex reinpacken. Man könnte Werte dann abspeichern oder senden wenn sie sich geändert haben. würde vermutlich das Datenvolumen doch ein wenig reduzieren. Aber darum kann man sich noch gedanken machen wenn erst mal alles läuft. Gruß Ingo
Leider noch nichts neues wegen dem KM271. War eben nochmal dran und habe mir mal die freien Anschlüsse angesehen. Da gibts noch 2 Klemmen "BF" wo man das "BFU" anschliessen kann. Benutzer Fernbedienung oder sowas. An den Klemmen liegt nur eine Versorgungsspannung an, es wird nichts gesendet. Scheinbar ist dann die BFU an dem Anschluss "master". Also auch uninteressant wenn man das Gerät nicht zur Hand hat. Habe eben auch nochmal verzweifelt nach Bildern von der KM271 gesucht, aber die Produktbilder die man findet sind so klein, dass man nichts erkennen kann. Scheint wohl absicht zu sein. Ich versuche doch mal, leihweise an so ein Modul zu kommen. Gruss, Malte
Hallo Rudi, ich habe Deine und meine Infos zum Aufbau der Datentelegramme mal als Diskussionsgrundlage in einer Excel-Tabelle dargestellt. Je Tabellenblatt ist ein Telegramm im Aufbau mit den bekannten, vermuteten und unbekannten Werten aufgeschlüsselt. Es sind jeweils die Werte mehrer Tage eingetragen. Deshalb ist die Tabelle auch ziemlich groß geworden (7,7 MB als ZIP). Ich freue mich auf rege Diskussion. Mario
@IngoF > Würde den Sklaven inkl. Wandler am liebsten auf eine eigene Platine > packen oder zumindest einen Steckplatz dafür vorsehen. Dann kann man > evtl hinterher noch die Platine gegen eine Sende/Empfangsplatine > austauschen falls es irgendwann mal oweit sein könnte. Ja, das habe ich mir auch überlegt, bin aber durch die Datenübertragung der 2107 erstmal von ab. Der Opto-Kram bräuchte den ADCMP370, einen LDO (5V) und dann den Optokoppler, dann hat man das sauber getrennt und hat hinter dem Opto. direkt das richtige Level für die Auswertung. Optokoppler für analoge Signale sind mir zu teuer, auch aus diesem Grund der LDO/LinearRegler. Eine Schaltung mit OPs vor dem Opto. wäre auch möglich, aber da werden, meiner Meinung nach, mehr Bauteile benötigt. Für die 2107 bräuchte man nur den Opto., aber dann zwei mal, die Signale haben schon 5V Level. Auf dem EMS-Bus haben wir nur 9600Baud, die per Hardware empfangen werden können, auf dem Bus der 2107 muß alles erstmal per Software empfangen werden und das bei einer relativ hohen Frequenz. Schon wegen der Software würde ich bei beiden Lösungen eine CPU benutzen wollen. Ich könnte eine Tüte Mega8 bekommen, dann stauben die nicht ein und laufen mal ;-). Ob die UART die Break-Erkennung hat kann ich jetzt nicht sagen, müsste ich mal im Datenblatt schauen. Für die Kommunikation wäre I2C nicht schlecht, dann könnte man weitere externe Module direkt an den Bus klemmen und gut. Multi-Master ist nicht weiter wild. > Ein Steckplatz > für ein einfache 2 oder 4 zeiliges LCD-Display mit Controller könnte man > auch einplanen. Da würden doch bestimmt ein paar Pins für freibleiben. > Außerdem könnte man dann noch ein paar Platinen mehr machen und vür > andere Funktionen gebrauchen. Hätte bestimmt ein paar > Anschlussprojekte... Ja, das leidige Steckverbinderproblem ... ;-) > Womit hast Du denn die Platinen geroutet? Eagle. > Die Auswertung würde ich dann aber vermutlich hinterher noch in dem > Cortex reinpacken. Man könnte Werte dann abspeichern oder senden wenn > sie sich geändert haben. würde vermutlich das Datenvolumen doch ein > wenig reduzieren. Aber darum kann man sich noch gedanken machen wenn > erst mal alles läuft. Auf alle Fälle, anders mache ich es auch nicht. 100x die gleiche Temperatur mit einem anderen Zeitstempel wird nicht wirklich benötigt. Wo und wie die Auswertung läuft ist erstmal nebensächlich.
@Mario Nicht schlecht, obwohl es Excel ist ;-) Hier ein paar Änderungen: MSG 08 00 18 25 : Fehlercode 07 : maximal Leistung (in %) (muss aber nicht sein) 08 : aktuelle Leistung (in %) 20 : evtl. auch 19 ist der Flammenstrom in uA (den Wert durch 10 teilen)
@Rudi Danke, habe Deine Änderungen gleich übernommen. War nachvollziehbar. Zum Auswerten und Suchen nehme ich gern Excel. Das Programm selbst ist dann in Delphi (immer noch das Übersichtlichste). Mir fehlen noch die Temperaturen der Heizkreise (habe 2) und der Mischer. Hast Du eine Idee, wo ich suchen könnte? bye, Mario
@Mario Ich schau eigentlich auch nur ins Service-Menu auf die Werte und versuche diese durch die Heizung zu verändern und dann im Datenstream zu finden. Ich rechne den dezimalen Wert in Hex um (X*1 und X*10 also 2 Werte) und dann suche ich den Wert im Stream. Dann wieder ändern usw.. Wie sieht eigentlich dein Hardwareaufbau aus ?
@IngoF hab es wohl übersehen ... > Kann mann den Cortex M3 auch über den USBprog programmieren, oder wie > programmierst Du den. Hast Du bis jetzt eine selbstentwickelte Schaltung > oder eine eingekaufte? Wenn UBSprog einen ARM programmieren kann (JTAG) dann sollte es funktionieren. Ich benutze zum Programmieren einen Luminary clon (mit ftdi2232d/usb) und Flachbandkabel (siehe Beitrag "Re: Zeigt her Eure Kunstwerke !"). Die fetten Steckverbinder für das JTAG gehen mir ganz schön auf ... Ich habe das Board selbst erstellt. Die Preise bei Luminary sind zwar okay, keine Frage, aber von den Bauteilkosten + Platine (nicht die Arbeitsstunden) ist man selbst noch billiger und hat was man haben möchte. Das Board kann man auf eine Trägerplatte schrauben die sich z.B. in einem Gehäuse befindet. Ansonsten ist an dem Board nichts besonderes. Alle programmierbaren Pinne sind über die Steckverbinder zugänglich und mehr oder weniger sortiert. Beim Verpolschutz ist noch ein Bock drin, aber für diesen Zweck ist es erstmal nicht problematisch.
Die Frameerkennung per Mega8 funktioniert. Habe den mit seiner einen UART zwischen den Levelshifter und dem Cortex angeschlossen. Leider gibt es noch die Bustimeouts, die ich noch nicht auswerte.
Angehängte Dateien:
-
gnuplot.png
23 KB
@ Rudi meine Hardware ist simpel. Entspricht dem Referenzlayout des eBus-Moduls mit angepassten Widerständen. Daran hängt der Serielle meines Servers. Die Erkennung der Timeouts zwischen den Telegrammen funktioniert ganz gut. Nur die kompletten Telegramme werden weiter verwendet. Die Variante mit einem Atmega ist natürlich das Beste. Habe hier noch ein WebCat-Board mit einem ATmega128 liegen, habe mich aber mangels C-Kenntnissen nicht daran versucht. Habe mich Heute den ganzen Tag mit SQL und gnuplot beschäftigt. Die Daten werden jetzt schön in einer MySQL-Datenbank gespeichert und über gnuplot angezeigt. Wie hast Du die Kurven in gnuplot geglättet? Bei mir sind noch Stufen zu sehen. Ich bin ja richtig erschrocken, wie oft meine Heizung den Brenner anschmeisst. Ich denke, die moduliert die Leistung, um die Brennerdauer zu verlängern und die Starts zu minimieren. Jetzt habe ich 6 Starts/h gezählt. Ist das normal? bye, Mario
@Mario > ein WebCat-Board mit einem ATmega128 liegen, habe mich aber mangels > C-Kenntnissen nicht daran versucht. Der 128 sollte auch funktionieren. Wenn ich nächste Woche mal den Timeout ausmessen kann poste ich mal den kompletten simplen Source. Mein Oszi steht noch an der 2107 :-/ > Wie hast Du die Kurven in gnuplot geglättet? Bei mir sind noch Stufen zu > sehen. Bei dir sieht das nicht schlecht aus. Mein Kurven sind nicht geglättet. Kannst du mal dein Script posten ? Die Zusammenfassung am unteren Bildrand finde ich gut. Der Brenner geht nicht mit voller Leistung an, siehe die Werte weiter oben, und aus diesem Grund kann der auch mal öffters angehen. Die Solltemperatur, nach der internen Temperaturkurve, ist übrigens der HK1_VL-Wert und in den Daten auch so kantig. Das ist kein gemessener Wert sondern der ermittelte von der Heizung. Anbei noch mein Script für gnuplot, es wird direkt in ein Bild gewandelt und dann auf dem Server ins www-Verz. verschoben ...
Nun die Daten für die 2107 mit Clock. Ich habe immer auf Level von CLK oder DATA getriggert. log_20091004.bin - Binärdaten - pro byte: bit0 CLK und bit1 DATA log_20091004.wav - die importierten Daten (alle Bytes verdoppelt) als WAV Viel Spass.
Hier der geparste Bitstream. Der Zeilenumbruch kommt bei jeder Daten/Clockanomalie (Leveländerung auf den Daten ohne Clock).
So sehen die Daten in etwa aus. 2 Byte anfrage und dann Anwort mit den Daten. Das letzte Byte scheint wieder diese ominöse CRC zu sein. Die Anfrage an 0xAC ist noch falsch geparst, evtl. stimmen die Daten absolut nicht ...
1 | A8 1C : A9 03 01 05 65 00 05 B6 |
2 | A8 0E : A9 65 00 05 05 2D 01 9B |
3 | AA FF : AB 00 00 AC 00 |
4 | AD 00 00 00 00 00 00 |
5 | A8 1C : A9 03 01 05 65 00 05 B6 |
6 | A8 0E : A9 65 00 05 05 2D 01 9B |
7 | AA FF : AB 00 00 AC 00 |
8 | AD 00 00 00 00 00 00 |
9 | A8 1C : A9 03 01 05 65 00 05 B6 |
10 | A8 0E : A9 65 00 05 05 2D 01 9B |
11 | AA FF : AB 00 00 AC 00 |
12 | AD 00 00 00 00 00 00 |
13 | A8 1C : A9 03 01 05 65 00 05 B6 |
14 | A8 0E : A9 65 00 05 05 2D 01 9B |
15 | AA FF : AB 00 00 AC 00 |
16 | AD 00 00 00 00 00 00 |
17 | A8 1C : A9 03 01 05 65 00 05 B6 |
18 | A8 0E : A9 65 00 05 05 2D 01 9B |
19 | AA FF : AB 00 00 AC 00 |
20 | AD 00 00 00 00 00 00 |
21 | A8 1C : A9 03 01 05 65 00 05 B6 |
22 | A8 0E : A9 65 00 05 05 2D 01 9B |
23 | AA FF : AB 00 00 AC 00 |
24 | AD 00 00 00 00 00 00 |
25 | A8 1C : A9 03 01 05 65 00 05 B6 |
26 | A8 0E : A9 65 00 05 05 2D 01 9B |
27 | AA FF : AB 00 00 AC 00 |
28 | AD 00 00 00 00 00 00 |
29 | A8 1C : A9 03 01 05 65 00 05 B6 |
30 | A8 0E : A9 65 00 05 05 2D 01 9B |
31 | AA FF : AB 00 00 AC 00 |
32 | AD 00 00 00 00 00 00 |
33 | A8 46 : A9 65 00 05 05 2D 01 9B |
34 | A8 1C : A9 03 01 05 65 00 05 B6 |
35 | A8 0E : A9 65 00 05 05 2D 01 9B |
36 | AA FF : AB 00 00 AC 00 |
37 | AD 00 00 00 00 00 00 |
38 | AA C7 : AB 78 0A 05 37 4B 00 0D |
39 | AA CE : AB 28 0A 02 FF FF FF 1A |
40 | A8 1C : A9 03 01 05 65 00 05 B6 |
41 | A8 0E : A9 65 00 05 05 2D 01 9B |
42 | AA FF : AB 00 00 AC 00 |
43 | AD 00 00 00 00 00 00 |
44 | AC 0D : AD FF 00 65 65 65 65 7B |
45 | A8 1C : A9 03 01 05 65 00 05 B6 |
46 | A8 0E : A9 65 00 05 05 2D 01 9B |
47 | AA FF : AB 00 00 AC 00 |
48 | AD 00 00 00 00 00 00 |
49 | AA 65 : AB 32 00 31 00 34 00 9D |
50 | AA 6C : AB 38 00 34 00 33 00 F3 |
51 | A8 1C : A9 03 01 05 65 00 05 B6 |
52 | A8 0E : A9 65 00 05 05 2D 01 9B |
53 | AA FF : AB 00 00 AC 00 |
54 | AD 00 00 00 00 00 00 |
55 | AA AB : AB 29 68 B0 31 A7 05 B0 |
56 | AA B2 : AB 00 A7 C2 05 00 3F F3 |
57 | AA B9 : AB 7E 7E 7E 8C 8C 8C 7F |
58 | AA C0 : AB A7 83 65 65 65 65 3C |
59 | A8 1C : A9 03 01 05 65 00 05 B6 |
60 | A8 0E : A9 65 00 05 05 2D 01 9B |
61 | AA FF : AB 00 00 AC 00 |
62 | AD 00 00 00 00 00 00 |
63 | AA DC : AB 34 07 00 00 09 1D 21 |
64 | AA E3 : AB 01 34 0B 19 00 0B F4 |
65 | AA EA : AB 25 0F 34 0E 1D 01 72 |
66 | AA F1 : AB 09 0B 16 34 13 16 25 |
67 | AA F8 : AB 01 11 22 35 00 00 1A |
68 | A8 1C : A9 03 01 05 65 00 05 B6 |
69 | A8 0E : A9 65 00 05 05 2D 01 9B |
70 | AA FF : AB 00 00 AC 00 |
71 | AD 00 00 00 00 00 00 |
72 | AA FF : AB 00 00 AC 00 |
73 | AD 00 00 00 00 00 00 |
74 | A8 1C : A9 03 01 05 65 00 05 B6 |
75 | A8 0E : A9 65 00 05 05 2D 01 9B |
76 | AA FF : AB 00 00 AC 00 |
77 | AD 00 00 00 00 00 00 |
78 | AC 06 : AD 00 00 00 00 00 00 00 |
79 | A8 1C : A9 03 01 05 65 00 05 B6 |
80 | A8 0E : A9 65 00 05 05 2D 01 9B |
81 | AA FF : AB 00 00 AC 00 |
82 | AD 00 00 00 00 00 00 |
Und hier mal auf eine Anfrage gefiltert:
1 | AA 6C : AB 38 00 34 00 33 00 F3 |
2 | AA 6C : AB 38 00 34 00 33 00 F3 |
3 | AA 6C : AB 38 00 34 00 33 00 F3 |
4 | AA 6C : AB 38 00 34 00 33 00 F3 |
5 | AA 6C : AB 38 00 34 00 33 00 F3 |
6 | AA 6C : AB 38 00 34 00 33 00 F3 |
7 | AA 6C : AB 38 00 34 00 33 00 F3 |
8 | AA 6C : AB 38 00 34 00 33 00 F3 |
9 | AA 6C : AB 38 00 34 00 33 00 F3 |
10 | AA 6C : AB 38 00 34 00 33 00 F3 |
11 | AA 6C : AB 38 00 34 00 33 00 F3 |
12 | AA 6C : AB 38 00 34 00 33 00 F3 |
13 | AA 6C : AB 38 00 34 00 33 00 F3 |
14 | AA 6C : AB 38 00 34 00 33 00 F3 |
15 | AA 6C : AB 38 00 34 00 33 00 F3 |
16 | AA 6C : AB 38 00 34 00 33 00 F3 |
17 | AA 6C : AB 38 00 34 00 33 00 F3 |
18 | AA 6C : AB 38 00 34 00 33 00 F3 |
19 | AA 6C : AB 38 00 34 00 33 00 F3 |
20 | AA 6C : AB 34 00 38 00 33 00 CF |
21 | AA 6C : AB 34 00 38 00 33 00 CF |
22 | AA 6C : AB 34 00 38 00 33 00 CF |
23 | AA 6C : AB 34 00 38 00 33 00 CF |
24 | AA 6C : AB 34 00 38 00 33 00 CF |
25 | AA 6C : AB 34 00 38 00 33 00 CF |
26 | AA 6C : AB 34 00 38 00 33 00 CF |
27 | AA 6C : AB 34 00 38 00 33 00 CF |
28 | AA 6C : AB 34 00 38 00 33 00 CF |
29 | AA 6C : AB 34 00 38 00 33 00 CF |
30 | AA 6C : AB 34 00 38 00 33 00 CF |
31 | AA 6C : AB 34 00 38 00 33 00 CF |
32 | AA 6C : AB 34 00 38 00 33 00 CF |
33 | AA 6C : AB 34 00 38 00 33 00 CF |
34 | AA 6C : AB 34 00 38 00 33 00 CF |
35 | AA 6C : AB 34 00 38 00 33 00 CF |
36 | AA 6C : AB 34 00 38 00 33 00 CF |
37 | AA 6C : AB 31 00 34 00 32 00 EA |
38 | AA 6C : AB 31 00 34 00 32 00 EA |
39 | AA 6C : AB 31 00 34 00 32 00 EA |
40 | AA 6C : AB 31 00 34 00 32 00 EA |
41 | AA 6C : AB 31 00 34 00 32 00 EA |
42 | AA 6C : AB 31 00 34 00 32 00 EA |
43 | AA 6C : AB 31 00 34 00 32 00 EA |
44 | AA 6C : AB 31 00 34 00 32 00 EA |
45 | AA 6C : AB 31 00 34 00 32 00 EA |
46 | AA 6C : AB 31 00 34 00 32 00 EA |
47 | AA 6C : AB 31 00 34 00 32 00 EA |
48 | AA 6C : AB 31 00 34 00 32 00 EA |
49 | AA 6C : AB 31 00 34 00 32 00 EA |
50 | AA 6C : AB 31 00 34 00 32 00 EA |
51 | AA 6C : AB 32 00 31 00 2B 00 74 |
52 | AA 6C : AB 32 00 31 00 2B 00 74 |
53 | AA 6C : AB 32 00 31 00 2B 00 74 |
54 | AA 6C : AB 32 00 31 00 2B 00 74 |
55 | AA 6C : AB 32 00 31 00 2B 00 74 |
56 | AA 6C : AB 32 00 31 00 2B 00 74 |
57 | AA 6C : AB 32 00 31 00 2B 00 74 |
58 | AA 6C : AB 32 00 31 00 2B 00 74 |
59 | AA 6C : AB 32 00 31 00 2B 00 74 |
60 | AA 6C : AB 32 00 31 00 2B 00 74 |
61 | AA 6C : AB 32 00 31 00 2B 00 74 |
62 | AA 6C : AB 32 00 31 00 2B 00 74 |
63 | AA 6C : AB 32 00 31 00 2B 00 74 |
64 | AA 6C : AB 32 00 31 00 2B 00 74 |
65 | AA 6C : AB 32 00 31 00 2B 00 74 |
66 | AA 6C : AB 32 00 31 00 2B 00 74 |
67 | AA 6C : AB 32 00 31 00 2B 00 74 |
68 | AA 6C : AB 32 00 31 00 2B 00 74 |
69 | AA 6C : AB 32 00 31 00 2B 00 74 |
70 | AA 6C : AB 32 00 31 00 2B 00 74 |
71 | AA 6C : AB 32 00 31 00 2B 00 74 |
72 | AA 6C : AB 32 00 31 00 2B 00 74 |
73 | AA 6C : AB 32 00 31 00 2B 00 74 |
74 | AA 6C : AB 32 00 31 00 2B 00 74 |
75 | AA 6C : AB 32 00 31 00 2B 00 74 |
76 | AA 6C : AB 32 00 31 00 2B 00 74 |
77 | AA 6C : AB 32 00 31 00 2B 00 74 |
78 | AA 6C : AB 32 00 31 00 2B 00 74 |
79 | AA 6C : AB 33 00 32 00 26 00 A9 |
80 | AA 6C : AB 33 00 32 00 26 00 A9 |
81 | AA 6C : AB 33 00 32 00 26 00 A9 |
82 | AA 6C : AB 33 00 32 00 26 00 A9 |
83 | AA 6C : AB 33 00 32 00 26 00 A9 |
84 | AA 6C : AB 33 00 32 00 26 00 A9 |
85 | AA 6C : AB 33 00 32 00 26 00 A9 |
86 | AA 6C : AB 33 00 32 00 26 00 A9 |
87 | AA 6C : AB 33 00 32 00 26 00 A9 |
EMS: 10 00 A5 CC VV ... CC: 01 für Sprache, 0C Uhrkorrektur, 06 Gebäudeart VV: z.B. 00 deutsch, 01 NL 10 08 16 08 VV 14 VV Pumpennachlaufzeit
@Rudi mit dem Quellcode für dem Atmega128, das wäre prima. Das Script für gnuplot habe ich beigefügt. Dieses ist aber noch nicht perfekt. Ich suche noch nach einer Möglichkeit, wie ich den Zeitraum, welcher ausgewertet werden soll, ändern kann. Bis jetzt lasse ich jedesmal die Scriptdatei mit Start- und Enddatum neu erzeugen. bye, Mario
Angehängte Dateien:
-
del.png
22 KB
Moin, danke. > Ich suche noch nach einer Möglichkeit, wie ich den Zeitraum, welcher > ausgewertet werden soll, ändern kann. Bis jetzt lasse ich jedesmal die > Scriptdatei mit Start- und Enddatum neu erzeugen. Kommt drauf an wie. Dynamisch wird das etwas zäh und könnte dann evtl. über ajax laufen. Statisch kann ich dir die rrdtools empfehlen, dort gibt es aber nur eine eingeschränkte grafische Möglichkeit. Anbei mal der Gaszähler über rrdtools. Die Datenbank für die rrdtools erstelle ich übrigens jede Stunde neu, da ich noch keine Lust auf eine Timestamporgie hatte und rrdtool kein mysql unterstützt. Kann man aber auch eleganter lösen.
> Die Variante mit einem Atmega ist natürlich das Beste. Habe hier noch > ein WebCat-Board mit einem ATmega128 liegen, habe mich aber mangels > C-Kenntnissen nicht daran versucht. Absolut keine ? Kompilieren und brennen geht aber ? > mit dem Quellcode für dem Atmega128, das wäre prima. siehe Anhang Kompiliert für den 128 (habe selbst keinen), sollte also laufen.
@Mario Hier eine kleine Optimierung für das Skript und deine Datenbank. Du kannst die Werte aus der 08 00 18 (10/11) in einen 16 Bit-Wert konvertieren und dann bei Gnuplot einfach die Bits abfragen: decode_status(t,w) = ( (int(t)&int(w)) == 0) ? 0 : 1 plot "data_14.txt" using 1:(decode_status($2,64)) with boxes notitle Kann Gnuplot eigentlich auch mit Hexwerten etwas anfangen ? Ich habe bisher nicht dazu gefunden ?
Angehängte Dateien:
-
del.png
14 KB
@Mario Ich habe deine Aufteilung in Gnuplot übernommen und denke das Bit 7 (0x40) vom Brennerstatus nicht richtig sein kann. Ich sehe da Aktivität ab 0 Uhr beim Brenner und der Pumpe im Warmwasserkreislauf ohne Gasverbrauch (die Heizung sollte um die Uhrzeit nicht an sein/Temperaturabsenkung). Kannst du das bestätigen ? Meine Bit-Masken sehen wie folgt aus (die 3 Diagramme unten): Zeile1: 8+4+1 Zeile2: 64 Zeile3: 32 Ich habe direkt 2 extra Temperatursensoren an den Vor-/Rücklauf der Holzheizung gehängt ;-) Der Testaufbau funktioniert soweit richtig gut.
@Rudi erstmal vielen Dank für den Quellcode. Beim ersten Anschauen habe ich aber nicht viel verstanden. Ich bin scheinbar C-inkompatibel ;-) Ein erster Kompilierungsversuch mit GNU AVR-GCC (Bestandteil des EtherNut-Paketes/ Nut/Os) ist gescheitert. Ich werde es mir nochmal genauer anschauen müssen. In dem Paket Nut/Os gibt es einen Beispiel-Code, welcher eine RS232 auf Netzwerk ( per Telnet) umsetzt. Vielleicht könnte man darauf aufbauen? Dann wären die Daten gleich im Netzwerk und man braucht keine weitere serielle Schnittstelle. Ich habe den Quellcode mal angehangen. Zu deiner Vermutung Brennerstatus: das ist nach meiner Ansicht das Bit 2 (04H) aus dem Byte 11 des 08-00-18-Telegramms. Im Absenkbetrieb bleibt dieses bei mir auf "0". Das Bit 6 (40H) muss die Warmwasserbereitung sein. Ist immer auf "1", wenn Warmwasser bereitet wird. Nächtliche Aktivität habe ich auch alle paar Tage, da gegen 01:00 Uhr die thermische Desinfektion läuft. Dann geht die Warmwassertemperatur bis auf 75 Grad hoch. bye, Mario
Angehängte Dateien:
-
del.png
13 KB
@Mario > Das Bit 6 (40H) muss die Warmwasserbereitung sein. Ist immer auf "1", > wenn Warmwasser bereitet wird. Nächtliche Aktivität habe ich auch alle > paar Tage, da gegen 01:00 Uhr die thermische Desinfektion läuft. Dann > geht die Warmwassertemperatur bis auf 75 Grad hoch. Die Desinfektion habe ich abgeschaltet, das bringt evtl. etwas, wenn das Wasser ein paar Wochen im Kessel steht. Wie im Bild zu sehen, ist das Flag eingeschaltet, aber es passiert nichts (kein Gas, keine Temperaturänderung). Muss ich mir die Tage nochmal genauer anschauen. > erstmal vielen Dank für den Quellcode. Beim ersten Anschauen habe ich > aber nicht viel verstanden. Ich bin scheinbar C-inkompatibel ;-) > Ein erster Kompilierungsversuch mit GNU AVR-GCC (Bestandteil des > EtherNut-Paketes/ Nut/Os) ist gescheitert. Ich werde es mir nochmal > genauer anschauen müssen. Ja, wenn du mir deine eingestellte CPU Geschwindigkeit sagst, dann kann ich das hier durchleiern. Ein Port mit LED wäre auch nicht schlecht. > In dem Paket Nut/Os gibt es einen Beispiel-Code, welcher eine RS232 auf > Netzwerk ( per Telnet) umsetzt. Vielleicht könnte man darauf aufbauen? > Dann wären die Daten gleich im Netzwerk und man braucht keine weitere > serielle Schnittstelle. Ich habe den Quellcode mal angehangen. Gleich ist gut ;-) Da braucht es mindestens einen Netzwerkkontroller. Ehrlich gesagt bin ich von Nut/OS nicht so begeistert.
@Malte Bayer Bist du schon weiter gekommen ? Ich hänge noch über den Daten der 2107 und komm nicht weiter. Die Daten sehen etwa so aus (in chronologischer Reihenfolge):
1 | A8 E7 : A9 01 FF FF 00 FF FF A8 |
2 | A8 EE : A9 01 21 00 84 21 21 61 |
3 | A8 F5 : A9 20 84 41 21 40 84 50 |
4 | A8 FC : A9 61 21 60 84 |
5 | AA 00 : AB 81 21 62 |
6 | AA 03 : AB 80 8A A1 27 A0 8D D0 |
7 | AA 0A : AB C1 2A C0 84 C2 90 CD |
8 | AA 11 : AB C2 90 C2 90 C2 90 0B |
9 | AA 18 : AB C2 90 C2 90 C2 90 0B |
10 | AA 1F : AB C2 90 C2 90 C2 90 0B |
11 | AA 26 : AB C2 90 C2 90 C2 90 0B |
12 | AA 2D : AB C2 90 C2 90 C2 90 0B |
13 | AA 34 : AB C2 90 C2 90 C2 90 0B |
14 | AA 3B : AB C2 90 C2 90 C2 90 0B |
15 | AA 42 : AB C2 90 C2 90 C2 90 0B |
16 | AA 49 : AB C2 90 C2 90 C2 90 0B |
17 | A8 1C : A9 03 01 05 65 00 05 B6 |
18 | A8 0E : A9 65 00 05 05 2D 01 9B |
Nun könnte man ja meinen das es sich beim zweiten Byte um eine Adresse handelt. Wenn ja, dann ändern sich die Daten nach einer gewissen Zeit nicht mehr im Speicher. Es wird gesendet, aber so gut wie keine Änderungen. Falls noch jemand eine Idee hat !? ...
Hallo, würde gerne bei der Decodierung mithelfen. Mit Java kann ich am PC die Daten nicht auseinanderhalten. Brauchbare Hardware habe ich auch nicht mehr. Die Brennersoftware bekomme ich nicht mehr zum laufen, und die Software die mit meinem Brenner funktioniert unterstützt meine PICs nicht. Muss also eigentlich wieder bei Null anfangen. Also Brenner kaufen und versuchen ob ich mit C klarkomme. Mit Assembler habe ich eigentlich weniger Probleme. Würde gerne mit Eagle eine Platine entwickeln mit der man dann evtl zusammen an der Software arbeiten könnte. Am liebsten würde ich den "Sklaven" austauschbar machen damit man evtl. nachträglich andere Bus-Systeme oder eben auch die Sendefunktion ünterstützen könnte. Die Idee mit der SD-Karte und Netzwerkanbindung ist schon mal genial. Dann kann die Platine fleissig Daten sammeln und man muss nicht immer einen PC laufen haben um die Daten zu loggen. Würde gerne auch einen Port für ein 4x20 LCD-Display einplanen damit die Platine entweder Daten anzeigen könnte oder eben auch noch für andere Projekte verwendbar ist. Vielleicht auch ein Tastaturport. Muss ja nicht alles am Anfang genutzt oder unterstützt werden. Dazu müssten wir uns für einen bestimmten "Sklaven", die andere Hardware und die Verbindung zwischen Cortex und dem Sklaven entscheiden. Würde die Platine mit Eagle entwerfen. @Rudi, kannst du mir einen Plan von deinem Cortex und dem ATmega zukommen lassen. @all wer hätte Interesse an so einer Platine? meine Mail: if38(at)arcor(punkt)de Gruß Ingo
Hallo Ingo, > Die Brennersoftware bekomme ich nicht mehr zum laufen, und die Software > die mit meinem Brenner funktioniert unterstützt meine PICs nicht. Muss > also eigentlich wieder bei Null anfangen. Also Brenner kaufen und > versuchen ob ich mit C klarkomme. Mit Assembler habe ich eigentlich > weniger Probleme. Diese Probleme mit PIC, Brenner und Software hatte ich auch. Und weisst Du, was ich gemacht habe? Dieses Tutorial angeschaut: http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial Dann ein Experimentierboard mit einem Atmega gekauft, welches Plug&Play am PC anschliessbar ist und es hat auf Anhieb funktioniert. Echt Klasse. Und nie wieder Assembler: Heute und morgen weiss jeder, wie er was in Assembler programmiert hat, aber übermorgen? Und dann noch Änderungen machen? C ist wirklich nicht schwierig und wahrlich keine Hexerei, da es Libraries und Demosourcen à gogo auf dem Internet gibt. Gruss Christian
@ Rudi:
>Bist du schon weiter gekommen ? Ich hänge noch über den Daten der 2107 und komm
nicht weiter.
Nein, ist zum verrückt werden. Kumpel hat irgendeine uralt-asbach
buderus steuerung an der öltherme. Der vermeintliche D-9 Stecker hat
sich als D-15 herausgestellt, also wohl keine echte RS232.
Und an ein "leihweise" Modul komme ich nicht ran. knappe Antwort "kaufen
ja, leihen nein" ;-(
Habe inzwischen auch nochmal die restlichen Pins, die auch nur annähernd
nach TTL Signal aussehen, versucht mittels max232 zu untersuchen.
Aber egal welche baudrate startstop paritykonfiguration - es kommt
immer nur müll und frame errors ohne ende an.
Hier noch ein HighRes-Bild vom ServiceKey: http://www.buderus.de/sixcms/media.php/1821/3743_Logamatic_Servicekey.tif http://www.buderus.de/Bilddatenbank/Regelsysteme/Logamatic_Fernwirksystem-2380747.html @Malte Bayer Lohnt sich eine Aufnahme mit dem ADC an den TTL Pins ? Ändern sich die Daten ? Ich habe die bisher nicht beachtet, da es auf dem Scope immer gleich aussieht. An einem habe ich eine Low-High-Low-Flanke mit etwas 27KHz gemessen, ist also nicht so fürchterlich schnell. Irgendwie müssen die Daten (Temperaturen etc.) an dieses Display **g**.
Kann ich dir nicht sagen ob sich das lohnt - interessant zu analysieren wärs aber schon. Bin mir allerdings ziemlich sicher dass diese Pins die Datenübertragung vom/zum display sind. Wie gesagt, habe kein Speicheroszi - habe nur mit dem timing und dem Trigger rumgespielt - ob da immer der gleiche Dreck übertragen wird weiss ich nicht, schliesse ich aber aus (wäre ja unlogisch).
>Dann ein Experimentierboard mit einem Atmega gekauft, welches Plug&Play >am PC anschliessbar ist und es hat auf Anhieb funktioniert. Echt Klasse. Wenn ich für mich selber eine Schaltung entwickele würde ich mir vermutlich einen neuen Microchip ICD2-clon kaufen und hätte auch keine Probleme mehr. Warum sollte ich wenn ich mich schon mit der Programmierung und den PICs vertraut gemacht habe aufeinmal einen neuen Controller nehmen, Neue Entwicklungsumgebung und mich in eine andere Programmiersprache einarbeiten? Die alten selbstgeschriebenen "Bibliotheken" kann man dann nicht mehr verwenden. >Und nie wieder Assembler: Heute und morgen weiss jeder, wie er was in >Assembler programmiert hat, aber übermorgen? Assembler hat auch Vorteile. Ist viel schneller als C-Code. Man weiß genau was der Controller macht und kann Programmspeicher sparen. Ob man jetzt in C, Assembler oder einer anderen Sprache screibt ist egal. Man hat in jeder Sprache probleme wenn man nach einer Pause alte Programme weiterentwickeln will und nichts im Quelltext dokumentiert hat. Wenn vernünftig dokumentiert wird ist das kein Problem. Ich hatte mir vorgestellt dass ich erstmal die Platine route und für alle interessierten fertigen lasse. Dazu brauch ich allerdings Informationen ob es beim Cortex und ATmega128 bleibt. Wichtig ist auch zu wissen wie die bisherige Software des ATmega128 aussieht. Wäre ja blöd wenn ich die bisher von der Software benutzten Anschlüsse für was anderes verplane und man mit der Software wieder von vorne anfangen kann. Wenn wir uns über die Hardware einig werden könnte ich loslegen. @Rudi welches Cortex-Board hast Du denn verwendet? Vielleicht kann ich dann ja irgendwie an den Schaltplan kommen. Gruß Ingo
@IngoF > welches Cortex-Board hast Du denn verwendet? Vielleicht kann ich > dann ja irgendwie an den Schaltplan kommen. Ich benutze den LM3S8938. Für den 8962 gibt es ein Eval-Board und den Schaltplan, kannst du bei Luminary runterladen. Hast du schon über ein fertiges ARM9 Board nachgedacht ? Ich kenne jetzt nicht die Preise, aber sollte im Vergleich zum Aufwand und den Kosten billiger werden. Auf dem würde dann wohl auch die Grafikerstellung direkt laufen. Ich würde erstmal überlegen was man wofür braucht. Wenn du nur einen kleinen Netzwerkkontroller benutzt, kannst du nicht ohne zweiten Rechner die Grafiken erstellen. Braucht man das oder nicht. Wie sollen die Daten gespeichert und ausgewertet werden und wieviel Daten werden es ? usw. usf. Mir reicht ein Cortex, da ich die Daten nur weiterleite und ein paar Sensoren mit dem auswerte. Was brauchst du ? Beim Sklaven kann ich erstmal nichts sagen, ein MEGA8 mit rund 11MHz funktioniert am ServiceKey, ob der für die 2107 ausreicht weiss hier niemand.
Also ich hatte daran gedacht dass ich ein Board erstellen würde was für alle Möglichkeiten funktionieren würde. Also Der Cortex mit Netztwerk und SD-Karte ist doch ideal. Die Daten sollten dann auf SD zwischen gespeichert werden und wenn ich meinen PC hochfahre werden Die Daten dann zum PC übertragen. Die Kommunikationsplatine mit dem Slave-Prozessor würde ich über einen Stecker miteinander verbinden. Dann ist es möglich die Platine für andere Bussysteme auszustauschen. Oder man kann hinterher doch eine zweiweg-Kommunikationsmodul einstecken. Da vermutlich noch genug Ein-/Ausgabepins frei sind würden die für ein LCD-Display heralten und vielleicht ein paar Taster. Die würden erst mal vernachlsääsigt und/oder nicht bestückt werden. Das Board könnte man auch noch für andere Entwicklungen verwenden. Denke ich hätte schon ein paar Ideen Ideal wäre es dann wenn mehrere sich hinterher eine Platine aufbauen wollen... Die Software könnte man zusammen entwickeln. (Software für PC, Slave und Master). So wie es aussieht ist ein großteil der Software ja schon geschrieben. (Visualisierung auf dem PC und Sammeln der Daten). Wäre doch am besten wenn man gemeinsam an einem Strang zieht und nicht mehrere Leute parallel das selbe Entwickeln/Programieren. Denke doch dass man auf einen Nenner bei der Software und Hardware kommen könnte, oder. Gruß Ingo
@Malte Bayer: Wir bräuchten dann also noch Messungen an folgenden Pins mit Augenmerk auf die TTL Signale !? Ich würde die TTL-Signale einzeln analog messen und dann komplett als Set ohne Zeitinformationen. Die anderen würde ich dann als zwei Sets messen (max 8bit), wenn denn da was anliegt. Ein Pin hatte noch 12V oder mehr, muss ich dann nochmal messen. 09 Ausgang Heizkreis1 Pumpe (an=5V, aus=0V) 03 5V gemessen, vielleicht ein binärer E/A? 04 5V gemessen, vielleicht ein binärer E/A? 05 0V gemessen, vielleicht ein binärer E/A? 06 0V gemessen, vielleicht ein binärer E/A? 08 0V gemessen, vielleicht ein binärer E/A? 10 0V gemessen, vielleicht ein binärer E/A? 11 0V gemessen, vielleicht ein binärer E/A? 12 0V gemessen, vielleicht ein binärer E/A? 13 0V gemessen, vielleicht ein binärer E/A? 14 0V gemessen, vielleicht ein binärer E/A? 19 5V gemessen, vielleicht ein binärer E/A? 20 5V gemessen, vielleicht ein binärer E/A? 21 0V gemessen, vielleicht ein binärer E/A? 15 TTL Signal Low-Aktiv, feste Pulsbreite, unregelmässiges Signal, könnte Frame start interrupt sein 16 TTL Signal variable Pulsbreite, sieht nach Datenübertragung aus 17 TTL Signal variable Pulsbreite, sieht nach einem Enable Signal aus 18 TTL Signal variable Pulsbreite, sieht nach einem Enable Signal aus 22 TTL Signal variable Pulsbreite, sieht nach Datenübertragung aus
@IngoF Ich habe das Board mit dem Cortex schon als Prototyp aufgebaut. Durch die Messungen an der 2107 konnte ich es auch schon mehr oder weniger testen. Mir ging es darum: so wenig wie möglich, so klein wie möglich und leicht adaptierbar. Also nur die CPU, Netzwerkbuchse, LDO, SD-Card, 2 LED, 2 Taster (einer Reset), Quarz (3 Stück). Das JTAG+UART ist über Flachbandkabel zugänglich und geht an einen JTAG-Luminary-Clone + UART. Alle nicht belegten Pins + JTAG + UART gehen mehr oder weniger sortiert an die Steckverbinder um die CPU. Damit kann ich (konnte ich bisher) alles anschliessen, von zu vielen speziellen Steckverbindern halte ich nicht viel, es sei denn das Board soll nur einem Zweck dienen. Bauteile sind fast alle 0402, das hat mir das Routing der Versorgung etwas erleichtert.
@IngoF Nachtrag: Schau dir mal bei watterott das LM3S8962 Board an. Mit JTAG kommst du damit unter 100€, billiger wird ein Kleinserienselbstbau leider auch nicht :-/. Die Luminary-Boards haben alle JTAG onbaord und dann noch mehr (z.B. Display) und sind nicht unbedingt viel teurer. Ich will dich aber nicht davon abhalten ein Board selbst zu bauen ;-)
@ Rudi:
1 | 16 TTL Signal variable Pulsbreite, sieht nach Datenübertragung aus |
2 | 22 TTL Signal variable Pulsbreite, sieht nach Datenübertragung aus |
3 | 23 Datenübertragung Differential zu pin 24 |
4 | 24 Datenübertragung Differential zu pin 23 |
Diese 4 Pins jeweils gegen GND scheinen interessant zu sein. Die anderen "TTL" dingens sind eher uninteressant, jetzt weiss ich auch was du meintest mit "ändert sich da was" ;) Die anderen Pins scheinen wirklich nur "1bit-EA" zu sein, also zeigen nur einen status an. Die ändern sich auch so gut wie gar nicht. Interessant wären 16+22 gleichzeitig recorden und 23+24 gleichzeitig. Zeitinformationen unwichtig, aber wichtig waere jeweils die beiden Pins nebeneinander sehen zu koennen (stereo wav?). Gruss, Malte
@Malte: Die 23/24 habe ich nun schon lang und breit gemessen, da ist zwar ein Datenstream, der ändert sich mit der Zeit aber so gut wie nicht. Siehe meine diversen Posts weiter oben (auch mit wav usw.). Mit dem ADC geht leider nur ein Pin, aber mit der anderen Methode ohne Zeitinformation gleich 8 Signale.
@Malte Bayer: Bei dir ist PIN 10 die Pumpe für WW. Hast du zufällig 2 HK ? Für den zweiten HK müsste es auch noch einen Pin geben. Die Flamme ist offensichtlich nicht auf dem Kabel. Ich habe alle 7 TTL-Pins mit 900KHz Auflösung aufgezeichnet, also 7 Signale mit Zeitinformation ! Die Datenaufbereitung könnte etwas dauern, es ist ein großer Datenhaufen angefallen ;-)
Okay, ging schneller als gedacht. Die wesentlichen Leitungen sind 23/24. Die anderen Leitungen senden zyklisch die gleichen Sequenzen. Mein vermutetes Format aus den Daten ohne Clock stimmt nicht. Mit Clock sieht es schon ganz anders aus. Ich habe kurz mal drüber geschaut und es der Anfang der Frames sieht wohl so aus: 1. 9 Clocks und ein ACK oder NACK auf der Datenleitung ohne Clock 2. 9 Clocks und ein ACK oder NACK auf der Datenleitung ohne Clock 3. 8 Clocks mit "Daten" ... usw. Malte Bayer schaust du mal über die Daten ? Samplerate ist 900000Hz. Die Dateien sind jeweils 56MB groß und du kannst diese direkt in Audacity importieren.
<Mit JTAG kommst du damit unter 100€, billiger wird <ein Kleinserienselbstbau leider auch nicht :-/. Naja, dabei bleibt es ja nicht... Dann müsste ich ja noch eine Experimentierboard mit einem ATmega128 kaufen. Und dann muss man auch noch alles irgendwie verdrahten. Und irgendwann müsste man sowieso eine vernünftige Platine mit allen Komponenten darauf entwickeln. Also müsste man die Prozessoren noch mal kaufen. Auslöten ist ja grober Unfug. Einfach die drei Platinen zusammenklatschen und in ein Gehäuse stopfen ist ja auch nicht das beste. Platzsparend wäre das nicht wirklich. Also warum nicht gleich eine richtige Platine entwickeln und auf die beiden Experimentierplatinen verzichten. Einen Port für ein LCD-Diaplay ist ja kein Problem. notfalls einfach einen 8-Bit Steckverbinder um einige Signale erweitern (Kontrast, und zusätzliche Signale. wer den nicht haben will bestückt die Platine eben mit der 8-Bit-Standartwanne. Die LCD-Displays hat ja vermutlich sowieso jeder herumfleigen. Entweder aus alten Faxen, Telefonen, Druckern oder sonstwo her. Warum also nicht Deine Miniversion entwickeln mit einer leicht abgeänderten Portwanne? Den Schaltplan bei Luminary für dieses Board habe ich noch nicht gefunden. Hast Du evtl einen Link? Gruß Ingo
@IngoF > Dann müsste ich ja noch eine Experimentierboard mit einem ATmega128 > kaufen. Und dann muss man auch noch alles irgendwie verdrahten. Und > irgendwann müsste man sowieso eine vernünftige Platine mit allen > Komponenten darauf entwickeln. Also müsste man die Prozessoren noch mal > kaufen. Auslöten ist ja grober Unfug. Glaub mir, es ist kein Unfug. Ein Platine mit alles Komponenten ist zu teuer und nie richtig für etwas anderes verwendbar. Das ist aber nur wahr, wenn man die Arbeit (die Stunden die man dort rein gesteckt hat) nicht auch für andere Projekte verwenden kann. Das ist bei einer Eier legenden Wollmilchsau nur bedingt möglich, alles viel zu speziell. > Einfach die drei Platinen zusammenklatschen und in ein Gehäuse stopfen > ist ja auch nicht das beste. Platzsparend wäre das nicht wirklich. Für den Heizungskeller oder wo auch immer die Heizung steht ist das kein Problem. Auf dem Tisch ist das "one in all" Board lästig. Ich will z.B. mehrere Temperatursensoren (werden wohl etwas mehr als 8) über Mini-USB (I2C) adaptieren, wenn ich die Steckverbinder alle auf dem Board platziere freut sich nur der Leiterplattenhersteller ... das mit den Modulen ist okay, es ist zwar noch nichts da, aber das ist meiner Meinung nach die richtige Richtung. > Also warum nicht gleich eine richtige Platine entwickeln und auf die > beiden Experimentierplatinen verzichten. Sagen wir mal eher Module und dann ist das Konzept wieder okay. > Einen Port für ein LCD-Diaplay ist ja kein Problem. notfalls einfach > einen 8-Bit Steckverbinder um einige Signale erweitern (Kontrast, und > zusätzliche Signale. wer den nicht haben will bestückt die Platine eben > mit der 8-Bit-Standartwanne. Die LCD-Displays hat ja vermutlich sowieso > jeder herumfleigen. Entweder aus alten Faxen, Telefonen, Druckern oder > sonstwo her. Ja, die Adaption von externen Komponenten macht eh jeder wie er Lust und Laune hat. > Warum also nicht Deine Miniversion entwickeln mit einer leicht > abgeänderten Portwanne? Ich mag die nicht. Die Kelchstifte sind so viel einfacher zu verdrahten ;-). Ich war aber auch mal deiner Meinung. > Den Schaltplan bei Luminary für dieses Board habe ich noch nicht > gefunden. Hast Du evtl einen Link? Kein Problem: Kits -> Evaluation Kits -> LM3S8962 Ethernet+CAN Evaluation Kits -> dann z.B.: EKC-LM3S8962 Evaluation Kit for CodeSourcery's G++ -> Stellaris LM3S8962 Evaluation Board User's Manual Sollte auch ohne Anmeldung funktionieren.
@Malte Bayer: Anbei nochmal alle Dateien mit gleicher Auflösung: data_0.bin - Pin 22 data_1.bin - Pin 18 data_2.bin - Pin 17 data_3.bin - Pin 16 data_4.bin - Pin 15 data_5.bin - Pin 24 data_6.bin - Pin 23
@Rudi heute habe ich Deinen C-Quellcode auf den Atmega128 angepasst und übersetzt. Als C-Unwissender hatte ich mich ja schon geoutet ;-). Mir fehlt noch das Verständnis, an welchem Port das TTL-Signal des EMS-Bus angeschlossen wird. In Deinem Code sehe ich immer nur, dass auf dem gleichen USART gelesen und geschrieben wird. Das kann ja aber nicht sein. Bitte hilf mir auf die Sprünge. Danke, Mario
@Mario Das ist okay so. An RX der UART hängst du den EMS-Bus und beim TX kommen die aufbereiteten Daten raus. Da ich es mit einem MEGA8 probiert habe, der hat nur eine UART, habe ich das so gemacht ;-) Baudrate bleibt, aber es werden mehr Daten durch den Header und die Längenangabe. Wenn du noch genügend freien Speicher hast, kannst du den Puffer etwas vergrößern.
@Mario Kannst du mal deinen avr-gcc Befehlszeile posten ? Du kannst dort direkt den Include-Pfad angeben und musst nicht die #include-Pfade in C anpassen.
Anbei mal ein geparster Stream von der 2107 (Pin 23/24). Das zweite Byte habe ich extra noch als binär angegeben. Die zweite Zahl ist die Zeit in Sekunden. Beispiel:
1 | DATA: 229.926741 A8 54 01010100 A9 : 3 1 5 101 1 5 166 |
2 | DATA: 229.929876 A8 5B 01011011 A9 : 12 3 1 101 101 101 7 |
3 | DATA: 229.933089 A8 62 01100010 A9 : 101 101 101 101 101 101 43 |
4 | DATA: 229.936233 A8 69 01101001 A9 : 40 10 10 17 101 101 150 |
5 | DATA: 229.939441 A8 70 01110000 A9 : 101 101 101 0 0 5 130 |
6 | DATA: 230.353317 A8 1C 00011100 A9 : 3 1 5 101 0 5 182 |
7 | DATA: 230.362004 A8 0E 00001110 A9 : 101 0 5 5 45 1 155 |
8 | DATA: 230.365306 AA FF 11111111 AB : 0 0 172 0 |
9 | DATA: 232.107041 A8 1C 00011100 A9 : 3 1 5 101 0 5 182 |
10 | DATA: 232.110352 A8 0E 00001110 A9 : 101 0 5 5 45 1 155 |
11 | DATA: 232.118099 AA FF 11111111 AB : 0 0 172 0 |
12 | DATA: 233.875018 A8 1C 00011100 A9 : 3 1 5 101 0 5 182 |
13 | DATA: 233.879603 A8 0E 00001110 A9 : 101 0 5 5 45 1 155 |
14 | DATA: 233.887958 AA FF 11111111 AB : 0 0 172 0 |
15 | DATA: 235.129592 A8 77 01110111 A9 : 246 101 1 6 101 101 2 |
16 | DATA: 235.594916 A8 1C 00011100 A9 : 3 1 5 101 0 5 182 |
17 | DATA: 235.615997 A8 0E 00001110 A9 : 101 0 5 5 45 1 155 |
18 | DATA: 235.624123 AA FF 11111111 AB : 0 0 172 0 |
19 | DATA: 236.928246 AA 50 01010000 AB : 101 101 101 101 101 1 7 |
20 | DATA: 236.930597 AA 57 01010111 AB : 101 251 40 43 60 101 140 |
21 | DATA: 236.933801 AA 5E 01011110 AB : 2 101 101 1 101 2 11 |
22 | DATA: 237.315292 A8 1C 00011100 A9 : 3 1 5 101 0 5 182 |
23 | DATA: 237.368396 A8 0E 00001110 A9 : 101 0 5 5 45 1 155 |
@Rudi Nach einem langen Wochenende (regnerisch und kalt) läuft der Atmega128 mit Deinem Programm am EMS-Bus der Heizung (RC35). Nochmal Danke für die Hilfe. Jetzt lassen sich die Daten viel leichter auswerten. Dem werde ich mich mal die nächste Zeit widmen. Mario
@Mario Da ich auch eine RC35 habe und irgendwie in diesem ganzen langen Thread den Überblick verloren habe, wollte ich fragen, was denn Du mit Deinem Atmega128 alles machen kannst oder ist das immer noch die Versuchsphase, die Daten zu entziffern? Gruss Christian
@Hennessy Der Atmega liest die Daten auf dem EMS-Bus, erkennt das Ende eines Telegramms und sendet das Telegramm mit Start- und Endzeichen sowie Längenangabe an den PC (Dank der super Hilfe durch Rudi). Die Telegrammaufzeichnung nur mit dem PC hat sich als zu langsam herausgestellt. Ein zwischengeschalteter Microprozessor ist absolut notwendig, da sonst das Telegrammende (ein fehlerhaftes Null-Byte) nicht ausgewertet werden kann. Im Rechner werden die Daten ausgewertet, angezeigt und in eine SQL-Datenbank geschrieben. Damit ist dann eine Langzeitanzeige als Diagramm möglich. Natürlich alles noch Testphase, aber ein Großteil geht schon. Zur Zeit werden gelesen: Kesseltemp Soll und Ist Anlagentemp Rücklauftemp Wamwassertemp Soll und Ist Außentemp Raumtemp (nur wenn RC35 im Wohnraum hängt, sonst Null) Anlagendatum/Zeit Zahl Brennerstarts Betriebstunden Laufzeit in Tagen Stunden WW-Bereitung Anzahl WW-Bereitung Fehler-/Statuscode Betriebsart Status von Brenner, Zündung, Flamme, Heizkreispumpe, Zirkulationspumpe, Dreiwegeventil Flammenstrom Wasserdruck im Heizkreis aktuelle Leistung Maximalleistung Leider fehlt mir momentan die Zeit, um richtig vorwärts zu kommen, aber der Winter naht ;-) bye, Mario
Angehängte Dateien:
-
del.png
15 KB
@Mario
> Raumtemp (nur wenn RC35 im Wohnraum hängt, sonst Null)
Das kann ich nicht bestätigen. Hier: RC35 am Brenner mit Raumtemperatur.
Mal eine andere Frage. Sieht die Vorlaufkurve der Heizung bei dir z.Z.
auch so merkwürdig aus ?
>Das kann ich nicht bestätigen. Hier: RC35 am Brenner mit Raumtemperatur. Muss aber eigentlich so sein. Habe zwar "nur" die RC30. Aber der Temperatursensor ist in der RC30 eingebaut. Wenn also die RC30 oder RC35 angeklemmt ist dürfte keine Temperatur gesendet werden. Also muss es dann irgendeine andere Temperatur sein die Du auswertest. Vielleicht eine errechnete Temperatur die von der Gebäudeart abhängt? Gruß Ingo @Mario / Rudi welches Format haben denn die Daten die vom ATmega128 gesendet werden? Dann könnte ich vielleicht noch mal ein Versuch mit meinen vorhanden PIC machen und die Daten im selben Format senden. Dann könnte ich vielleicht Euer Script laufen lassen und beim decodieren mithelfen. Ob ich mir dann auch irgendwelche Hardware baue oder sogar den RS232-Gateway von Buderus nehme habe ich noch nicht entschieden.
Hi, habe hier zu Hause auch eine Buderus Heizung mit RC30 und BC10. Habe mir den Thread jetzt ein paar Mal durchgelesen, blicke aber nicht so richtig durch :) Also: Grundsätzlich geht es hier im Thread um 2 verschiedene Protokolle/Systeme, einmal den EMS-Bus, der u.A. an der Klinkenbuchse des BC10 anliegt und zum anderen geht es um das Protokoll der Logamatic 2107, soweit richtig? :) Das Protokoll der 2107 ist also nicht identisch mit dem EMS-Bus (also dem was an der Klinkenbuchse ankommt). Gibt es nun irgendwie eine Protokollbeschreibung vom EMS-Bus? Mir ist das noch nicht ganz klar :/ Auf der Klinkenbuchse ist also einmal +12V, GND und das Signal. Auf der Signalleitung können alle angeschlossenen Teilnehmer senden und empfangen (RX=TX , so stand es weiter oben) und man kann mit einem UART auf 9600Baud begrenzt (mit Fehlern?) alles was auf dem EMS-Bus gesendet wird mitlesen? Bitte korrigiert mich wenn ich irgendwo falsch liege :)
> Muss aber eigentlich so sein. Habe zwar "nur" die RC30. Aber der > Temperatursensor ist in der RC30 eingebaut. Wenn also die RC30 oder RC35 > angeklemmt ist dürfte keine Temperatur gesendet werden. Angeklemmt ist die doch immer. > Also muss es dann irgendeine andere Temperatur sein die Du auswertest. > Vielleicht eine errechnete Temperatur die von der Gebäudeart abhängt? Die Temperatur wird mir als Raumtemperatur im Menü angezeigt, ich bin mir also 100%ig sicher ;-) > welches Format haben denn die Daten die vom ATmega128 gesendet werden? 0xAA 0x55 <DATA> <LEN> 0xAA 0x55 DATA die Daten vom EMS Bus LEN das Längenbyte (Anzahl der DATA-Bytes) Eine CRC-16 wäre auch nicht schlecht, auf der UART sind ja immer zyklische Fehler vorhanden. > Ob ich mir dann auch irgendwelche Hardware baue oder sogar den > RS232-Gateway von Buderus nehme habe ich noch nicht entschieden. An das Gateway konnte man doch diese 1000km Kabel antütern oder ? Ich glaube das Gateway bekommt man für etwa 250€. Ganz schöner Preis, für ne Serielle ;-)
@Niclas richtig beschrieben, hier geht es parallel um zwei verschiedene Sachen, den EMS-Bus (bei mir und Rudi) und die 2107. Ich bastel nur am EMS-Bus. Eine Protokollbeschreibung gibt es noch nicht. Ich hatte mal eine Excelliste gepostet (weiter oben im Thread). Diese enthält aber noch Fehler, da die Telegramme nur mit dem PC aufgezeichnet waren. Im Moment ergänze ich die Liste gerade, da jetzt alle Telegramme richtig ankommen. Alles Erkannte basiert nur auf Diagnose und Raten. Beschreibung gibt Buderus (jetzt Bosch) nicht raus. Korrigierte Liste kommt die nächsten Tage. @Rudi Ich hab doch noch keine Vorlauffühler wie Du. Aber gerade habe ich zwei interessante Daten im Telegramm 11 00 9C Byte4+5 und 21 00 AB Byte 5+6 gefunden. Das dürften die VL-Temp. von Heizkreis 1 und 2 sein. Muss ich erst in die SQL-Datenbank implementieren. bye, Mario
>Angeklemmt ist die doch immer. Vielleicht war es ja auch ein Misverständnis. Hatte den Satz "Raumtemp (nur wenn RC35 im Wohnraum hängt, sonst Null)" so verstanden dass die RC35 in der Zeit garnicht angeklemmt ist. >0xAA 0x55 <DATA> <LEN> 0xAA 0x55 Hatte mir auch schon Gedanken gemacht wie ich die Telegramme übertragen wollte. Ich hätte die dann Als Hex codiert übertragen und nach jedem Telegramm ein Enter geschickt. Dann hätte ich mit 115,2 KBit übertragen (Also 1 Byte senden wärend der Abtast-Pause zwischen zwei Bits die Empfangen werden. So ist das natürlich auch eine gute Idee. CRC16 ist ja nicht ganz so einfach zu berechnen. Um vieles Einfacher wäre ein einfaches XOR der Bytes als Prüfsumme anzuhängen. >...für etwa 250€. Ganz schöner Preis... Genau deswegen überdenke ich das ja schon seit 2003. Damit wäre es ja nicht getan Die Software kommt ja auch noch dazu. Für Heizungsfachbetriebe könnte sich sowas ja lohnen. Aber für Privatanwender ist das ja fast sinnlos. Würde natürlich gerne die Heizprogramme am PC einstellen. Die Dreherei an der RC30 ist ja viel zu Umständlich. Dazu müsste man aber herausbekommen wie die Prüfsumme berechnet wird. Ein einfaches XOR oder CRC8 scheint es nicht zu sein. Habe schon mal mit verschiedenen Anfangs und Endwerten und Bitfolge herumgerechnet, habe aber nichts herausfinden können. Vielleicht haben die ja auch eine eigenes Polynom dafür genommen? Vielleicht werd ich da ja noch irgendwann mal was herausbekommen. Oder irgend eine Idee zur Prüfsumme? Oder ist das vielleicht doch keine? Gruß Ingo
@Mario Vielen Dank für Deine Zusammenfassung, jetzt ist mir einiges klarer. Genau das, was ich suche, deshalb werde ich mich auch mal dahinter klemmen. Bin schonmal gespannt auf die korrigierte Liste. Gruss Christian
@Mario > Ich hab doch noch keine Vorlauffühler wie Du. > Aber gerade habe ich zwei interessante Daten im Telegramm 11 00 9C > Byte4+5 und 21 00 AB Byte 5+6 gefunden. Das dürften die VL-Temp. von > Heizkreis 1 und 2 sein. Muss ich erst in die SQL-Datenbank > implementieren. Die sehe ich hier nicht. Sind das evtl. Lesefehler ??? Adresse 11 und 21 ???
Hallo Leute, ich habe den Thread jetzt mehrfach gelesen, und blicke vielleicht deswegen nicht mehr durch. Pin 23/24 an der Logamatic 2107 zwischen Controllerplatine und Hauptplatine sind zu verwenden? Welche Pegelanpassung? Welches Protokoll? Hat schon jemand eine Liste mit Telegrammen? Würde da auch gerne einsteigen. mfg Chris
@Rudi das sind keine Lesefehler. Sowas gibt es bei mir nicht mehr ;-) 11 ist der Absender WM10 (Pumpe Heizkreis 1) Beispiel: 11 08 1E 00 00 D1 B3 00 Byte 4+5: Vorlauf HK1 IST Byte 6 : scheint auch eine Temperatur zu sein, für Rücklauf aber zu niedrig 21 ist der Absender MM10 (Pumpe und Mischer Heizkreis 2) Beispiel: 21 00 AB 00 05 00 CD 00 9C 01 10 F9 00 Byte 4 : Vorlauf HK2 SOLL Byte 5+6: Vorlauf HK2 IST Byte 8 : Mischersteuerung Hast Du die Anzeige Außentemperatur schon für Minusgrade korrigiert? Das Highbyte wird dann FF. Ich kann das System noch nicht erkennen. Rückwärtsrechnen von FFFF passt auch nicht. Hast Du eine Idee? bye, Mario
@Mario > das sind keine Lesefehler. Sowas gibt es bei mir nicht mehr ;-) Du hattest ja 2 Heizkreise ... Lesefehler gibt es noch, wenn der Bustimeout aufschlägt wird am Anfang einer Nachricht ein falsches Byte gelesen. B3 ist die CRC: 11 08 1E 00 00 D1 B3 00 ^^ Byte 0 mit Frameerror ^^----CRC > Hast Du die Anzeige Außentemperatur schon für Minusgrade korrigiert? Nein, ich muss noch warten ;-) > Das Highbyte wird dann FF. Ich kann das System noch nicht erkennen. > Rückwärtsrechnen von FFFF passt auch nicht. Hast Du eine Idee? Hast du ein Beispiel ? Wir haben hier noch keine Temperaturen unter 0°C.
Ich sehe hier noch:
10 08 1A 00 27 64 64 00 F1 00
10 88 14 00 03 6E 00
10 08 35 00 11 11 30 00
10 00 A3 00 0A 01 01 85 00
10 00 A2 00 00 00 00 00 00 00 00 00 00 00 18 00
08 00 07 00 03 01 00 00 00 00 00 00 00 00 00 00 00 DA 00
^^ ändert sich ab und zu auf 0
Die ich nicht zuordnen kann.
@Rudi,
leider habe ich für die Minusgrade kein Beispiel mehr. Auch bei mir sind
es jetzt 10 Grad plus.
Nachvollziehen konnte ich, dass -0,1 °C als FFFFH dargestellt wird.
-0,2 °C könnte FFFEH sein, ich hatte allerdings den Eindruck, dass die
negative Temp. eine andere Auflösung hat (event. 0,05 °/Digit).
Werde ich lt.Wetterbericht Ende nächster Woche testen können. Ich wohne
in einer kalten Gegend ;-)
Hier mal eine Liste aller Telegramme, die es bei mir gibt:
Absender = UBA3 (Brenner)
08 00 07 keine Änderungen
08 00 18 Kesseltemp Soll/Ist, Leistung WWTemp,
Ruecklauftemp, Fehlercode, Betriebsart, Druck
08 00 19 Außentemp, Brennerstarts, Betriebststundenzaehler
08 00 34 WWTemp Soll/Ist, Zähler WW-Bereitung, Status 3-Wegeventil
08 00 1C keine Änderungen
08 10 10 Lebenszeichen?
08 10 11 Lebenszeichen?
08 10 14 irgendwelcher Zähler
Absender = BC10
09 10 keine Änderungen
Absender = RC35
10 00 06 Datum/Zeit, Betriebszeit
10 00 48 unklar
10 00 3E Raumtemp.
10 00 A2 keine Änderungen
10 00 A3 3 Temperaturen (unklar)
10 08 35 unklar
10 08 1A unklar
10 11 9D unklar
10 21 AC unklar
10 88 10 Lebenszeichen?
10 88 11 Lebenszeichen?
10 88 14 keine Änderungen
10 89 29 keine Änderungen
Absender = WM10 (Pumpe HK1)
11 00 9C Vorlauftemp HK1
11 08 1E Vorlauftemp HK1
Absender = MM10 (Pumpe/Mischer HK2)
21 00 AB Vorlauftemp Soll/Ist HK1, Mischersteuerung
Wie immer als Diskussionsgrundlage.
bye,
Mario
@Mario > Nachvollziehen konnte ich, dass -0,1 °C als FFFFH dargestellt wird. > -0,2 °C könnte FFFEH sein, ich hatte allerdings den Eindruck, dass die > negative Temp. eine andere Auflösung hat (event. 0,05 °/Digit). Die Änderung der Auflösung wäre eigentlich untypisch. Das Problem wird sich in den nächsten Wochen aber von selbst erledigen ;-) Jedes Modul hat noch eine Versionsnummer, ich vermute das die in den Nachrichten ohne Änderung verschickt werden. Es könnte sich aber auch um Werte von "fehlenden" Sensoren handeln. Ich werde in den nächsten Tagen meine alten Logdateien parsen und eine Liste der Nachrichten erstellen. In 3 Monaten sind etwa 10GB an Rohdaten aufgelaufen die langsam mal wech können.
zur 2107: Bei den Nachrichten handelt es sich offenbar um eine Art "ECO-CAN" Bus von B.. Die Datenlänge spricht dafür, die Speicheradressen sind aber noch etwas unklar. Jeder Teilnehmer auf dem Bus hat eine Adresse und einen Speicherbereich der ausgelesen oder beschrieben werden kann. Initial sollte der komplette Speicher übertragen werden (ich habe leider noch keine Einschaltsequenz der Anlage) und danach nur Speicherbereiche in denen Änderungen stattgefunden haben. Da die Adressierung des Speichers noch unklar ist, sehen die Nachrichten immer gleich aus, welches Bit MSB und LSB ist, ist leider auch noch unklar ... die dezimale 65 in den Daten ist wohl ein Lückenfüller für nicht vorhandene Werte bzw. Werte die nicht beschrieben werden sollen/können.
Hallo, ich lese hier sehr interessiert mit, da ich ebenfalls die 2107 anzapfen möchte. Vieleicht könnte uns folgende Unterlagen weiterhelfen: http://zeroflag.web.elte.hu/buderus1.pdf http://zeroflag.web.elte.hu/buderus2.pdf
Ich habe die Beschreibung für die 4000er. Dort sehen die
ECO-CAN-Adressen etwas anders aus. Die Daten aus den Dokumenten werden
offensichtlich durch die Adapter-Karte auf den Bus umgesetzt. Auf dem
Bus sieht es so aus:
<ADDR> <FLAG?> <ADDR+1> <D1> <D2> <D3> <D4> <D5> <D6> <CRC?>
Ich dachte erst an I2C, aber das Protokoll passt nicht 100%ig.
Im "FLAG" könnte der Offset und ein paar unbekannte Bits kodiert sein.
Es ist jedenfalls kein 8 Bit Offset.
Mal ein Beispiel. Das Flag ist mit 0x07 (#1) und 0xF8 (#2) maskiert und
die Adressen sind 2 Bits nach rechts verschoben. Die Daten sehen jetzt
schon etwas anders aus und der mögliche Offset passt auch zu den Daten:
#1 #2
DATA: 020.342196 55 02 78 01111010 55 : 28 05 65 65 65 09 93
DATA: 049.014864 55 02 B0 10110010 55 : 00 A7 C2 05 00 3F F3
DATA: 050.752797 55 02 E8 11101010 55 : 1D 0B 34 0B 19 00 0A
DATA: 083.720304 55 02 78 01111010 55 : 28 05 65 65 65 09 93
DATA: 088.861636 55 02 B0 10110010 55 : 00 A7 C2 05 00 3F F3
DATA: 090.602838 55 02 E8 11101010 55 : 1D 0B 34 0B 19 00 0A
DATA: 123.567026 55 02 78 01111010 55 : 28 05 65 65 65 09 93
DATA: 135.510151 55 02 B0 10110010 55 : 00 A7 C2 05 00 3F F3
DATA: 137.248078 55 02 E8 11101010 55 : 1D 0B 34 0B 19 00 0A
DATA: 170.215767 55 02 78 01111010 55 : 28 05 65 65 65 09 93
DATA: 206.820734 55 02 B0 10110010 55 : 00 A7 C2 05 00 3F F3
DATA: 208.558722 55 02 E8 11101010 55 : 1D 0B 34 0B 19 00 0A
DATA: 241.526318 55 02 78 01111010 55 : 28 05 65 65 65 09 93
DATA: 256.653552 55 02 78 01111010 55 : 28 05 65 65 65 09 93
Angehängte Dateien:
Zur 2107: Soooooo, ich konnte die Angaben in den Dokumenten von B., bezüglich dem ersten kompletten Datenaustausch, heute verifizieren. Nach dem Einschalten wird ein Datenwulst auf dem Bus verschickt und danach geht es eher ruhig zu (siehe Anhang). Nebenbei habe ich die Anlage "virtuell" verkabelt und habe jetzt den unbekannten "realtime"-Log vom Bus jederzeit zur Verfügung. Falls jemand Interesse an den Daten hat bitte melden, ich weiss das ein Busmitschnitt und das Parsen der Daten "noch" etwas kompliziert ist ...
Nachtrag: Auf dem Bild ist der rechte Bereich von LOG1 und LOG2 nicht identisch. Beim zweiten Mitschnitt kam kurz nach dem Einschalten eine Anforderung für die Warmwasserbereitung, ein möglicher Grund dafür ...
Angehängte Dateien:
-
happy_hacking.png
280 KB
zur 2107: Ich habe jetzt ein Bedienteil gesponsort bekommen ;-). Es beschwert sich über den fehlenden Temperaturfühler und Kessel ... Update:
1 | 01 +5V |
2 | 02 GND |
3 | 03 5V gemessen, vielleicht ein binärer E/A? |
4 | 04 Input (0V Displayeinheit aus/ 5V Displayeinheit an + Bustraffic) |
5 | 05 0V gemessen, vielleicht ein binärer E/A? |
6 | 06 0V gemessen, vielleicht ein binärer E/A? |
7 | 07 NC |
8 | 08 0V gemessen, vielleicht ein binärer E/A? |
9 | 09 Ausgang Heizkreis1 Pumpe (an=5V, aus=0V) |
10 | 10 Pumpe WW (0V aus / 5V an) |
11 | 11 0V gemessen, vielleicht ein binärer E/A? |
12 | 12 0V gemessen, vielleicht ein binärer E/A? |
13 | 13 0V gemessen, vielleicht ein binärer E/A? |
14 | 14 0V gemessen, vielleicht ein binärer E/A? |
15 | 15 TTL Signal Low-Aktiv, feste Pulsbreite, unregelmässiges Signal, könnte Frame start interrupt sein |
16 | 16 TTL Signal variable Pulsbreite, sieht nach Datenübertragung aus |
17 | 17 TTL Signal variable Pulsbreite, sieht nach einem Enable Signal aus |
18 | 18 TTL Signal variable Pulsbreite, sieht nach einem Enable Signal aus |
19 | 19 5V gemessen, vielleicht ein binärer E/A? |
20 | 20 5V gemessen, vielleicht ein binärer E/A? |
21 | 21 0V gemessen, vielleicht ein binärer E/A? |
22 | 22 TTL Signal variable Pulsbreite, sieht nach Datenübertragung aus |
23 | 23 Datenübertragung Differential zu pin 24 |
24 | 24 Datenübertragung Differential zu pin 23 |
25 | 25 Output / 50hz sinus der fast wie dreieck aussieht 0,16V AC gemessen, ab und zu störungen messbar |
26 | 26 NC |
zur 2107:
Das letzte Byte einer Nachricht ist die CRC. Ich konnte ein paar Daten
erkennen:
A8 07 : A9 65 11 20 3C 00 22 1A
A8 3F : A9 65 11 20 3C 00 22 1A
**
**--------- 0 Nacht, 1 Tag, 2 Auto
**-------------Temp Nacht eingestellt (0.5
Auflösung)
**----------------Temp Tag eingestellt (0.5 Auflösung)
AA 57 : AB 65 FB 28 20 3C 65 D4
**
**
**
**----------------Temp WW eingestellt
Der BUS ist übriegens ein I2C-Bus. Am EEProm liegen die gleichen Daten an. Ich habe mal das Datenblatt angehängt.
Ich habe den Speicher ausgelesen: PAGE0 0xff PAGE1 0xff PAGE2 0xff PAGE3 0xff PAGE4 DATEN PAGE5 DATEN PAGE6 DATEN ein paar Byte, der Rest 0xFF PAGE7 0xff Andere Teilnehmer (die CPU) befindet sich wohl nicht auf dem Bus.
Hier nochmal die Pins. Ohne Pin15 (High) wird der Kessel/WW als fehlend angezeigt. Jetzt sehe ich schonmal die alten Werte vom WW/Kessel usw. (auf dem Tisch) ;-)
1 | 01 +5V |
2 | 02 GND |
3 | 03 5V gemessen, vielleicht ein binärer E/A? |
4 | 04 Input (0V Displayeinheit aus/ 5V Displayeinheit an + Bustraffic) |
5 | 05 OUTPUT ??? (0V) |
6 | 06 OUTPUT ??? (0V) |
7 | 07 NC |
8 | 08 OUTPUT ??? (0V) |
9 | 09 Ausgang Heizkreis1 Pumpe (an=5V, aus=0V) |
10 | 10 Pumpe WW (0V aus / 5V an) |
11 | 11 OUTPUT ??? (0V) |
12 | 12 OUTPUT ??? (0V) |
13 | 13 OUTPUT ??? (0V) |
14 | 14 OUTPUT ??? (0V) |
15 | 15 ALIVE (HIGH) kessel/ww TTL Signal Low-Aktiv, feste Pulsbreite |
16 | 16 OUTPUT SIGNAL (unknown) |
17 | 17 OUTPUT SIGNAL (unknown) |
18 | 18 OUTPUT SIGNAL (unknown) |
19 | 19 INPUT ??? (5V) |
20 | 20 INPUT ??? (5V) |
21 | 21 OUTPUT ??? (0V) |
22 | 22 OUTPUT SIGNAL (unknown) |
23 | 23 SDA |
24 | 24 SCL |
25 | 25 OUTPUT 50hz sinus der fast wie dreieck aussieht 0,16V AC gemessen, ab und zu störungen messbar |
26 | 26 NC |
Nachtrag: Die Temperaturen werden offensichtlich über über Pin 15 übertragen. Wenn ich dort direkt SCL oder SDA anschliesse gibt es Temperaturänderungen im Display die im EEProm hinterlegt werden. Es geht jetzt eingentlich nur um die richtigen Adressen im EEProm und dann wars das eigentlich ...
Update:
1 | 01 +5V |
2 | 02 GND |
3 | 03 5V gemessen, vielleicht ein binärer E/A? |
4 | 04 INPUT (0V Displayeinheit aus/ 5V Displayeinheit an + Bustraffic) |
5 | 05 OUTPUT Relais Brenner (an=5V, aus=0V) |
6 | 06 OUTPUT ??? (0V) |
7 | 07 NC |
8 | 08 OUTPUT ??? (0V) |
9 | 09 OUTPUT Relais HK1 Pumpe (an=5V, aus=0V) |
10 | 10 OUTPUT Relais WW Pumpe (0V aus / 5V an) |
11 | 11 OUTPUT Relais ZIRKPUMPE (0V aus / 5V an) |
12 | 12 OUTPUT Relais MISCHER (0V zu / 5V auf) |
13 | 13 OUTPUT ??? 0V => 5V after successfull Init |
14 | 14 OUTPUT Relais HK2 Pumpe (0V aus / 5V an) |
15 | 15 INPUT ALIVE/DATA (HIGH) kessel/ww ... |
16 | 16 OUTPUT SIGNAL (unknown) 4x HIGH/LOW 4*450ms 1x LOW 1*450ms |
17 | 17 OUTPUT SIGNAL (unknown) (1sec HIGH/1sec LOW) |
18 | 18 OUTPUT SIGNAL (unknown) (450ms HIGH/450ms LOW) |
19 | 19 OUTPUT SIGNAL (unknown) |
20 | 20 INPUT ??? (5V) |
21 | 21 OUTPUT ??? (5V) |
22 | 22 OUTPUT SIGNAL (unknown) |
23 | 23 SDA |
24 | 24 SCL |
25 | 25 OUTPUT 50hz sinus der fast wie dreieck aussieht 0,16V AC gemessen, ab und zu störungen messbar |
26 | 26 NC |
So, zu den Temperaturen bei der 2107. Leider werden nur die programmierbaren Temperaturen im EEProm gespeichert. Die eigentlichen Temperaturen werden über einen extra Bus übertragen. Es gibt 8 mögliche Temperaturen (ADC-Werte), wobei eine/r die Referenz ist. Ich konnte hier schon die Temperaturen per Hardwaresimulation durchfahren, aber die Referenz ist noch etwas undurchsichtig, geht aber in die Berechnung der Temperaturen mit ein. In der Serviceanleitung sind die Kurven und entpsrechenden Werte der Widerstände abgebildet. Hat jemand zufällig Widerstandskurven zur Temperatur in digitaler Form die denen aus der Serviceanleitung entsprechen ???? Hier das Update der Pins:
1 | 01 +5V |
2 | 02 GND |
3 | 03 5V gemessen, vielleicht ein binärer E/A? |
4 | 04 INPUT (0V Displayeinheit aus/ 5V Displayeinheit an + Bustraffic) |
5 | 05 OUTPUT Relais Brenner (an=5V, aus=0V) |
6 | 06 OUTPUT ??? (0V) |
7 | 07 NC |
8 | 08 OUTPUT ??? (0V) |
9 | 09 OUTPUT Relais HK1 Pumpe (an=5V, aus=0V) |
10 | 10 OUTPUT Relais WW Pumpe (0V aus / 5V an) |
11 | 11 OUTPUT Relais ZIRKPUMPE (0V aus / 5V an) |
12 | 12 OUTPUT Relais MISCHER (0V zu / 5V auf) |
13 | 13 OUTPUT ??? 0V => 5V after successfull Init |
14 | 14 OUTPUT Relais HK2 Pumpe (0V aus / 5V an) |
15 | 15 INPUT ADC (Value => Signal High Time) |
16 | 16 OUTPUT ADC ADDR 0 |
17 | 17 OUTPUT ADC ADDR 1 |
18 | 18 OUTPUT ADC ADDR 2 |
19 | 19 OUTPUT SIGNAL UART 1200 Baud (7n1) ??? |
20 | 20 INPUT ??? (5V) |
21 | 21 OUTPUT ADC RESET ??? |
22 | 22 OUTPUT ADC SYNC |
23 | 23 SDA |
24 | 24 SCL |
25 | 25 OUTPUT 50hz sinus der fast wie dreieck aussieht 0,16V AC gemessen, ab und zu störungen messbar |
26 | 26 NC |
27 | |
28 | ADC ADDR |
29 | --------
|
30 | 0x00 ... KESSEL |
31 | 0x01 ... AUSSEN |
32 | 0x02 ... WW |
33 | 0x03 ... ??? |
34 | 0x04 ... ??? |
35 | 0x05 ... ??? |
36 | 0x06 ... VORLAUF |
37 | 0x07 ... REF |
Identifizierung Temperatursensoren (2107) aus den Kurven im Serviceheft: http://www.fuehlersysteme.de/resistance_characteristics_de.pdf Außentemperatur: NTC 10Kohm Kesselwasser : NTC 10Kohm Raumtemp : NTC 10Kohm Abgas : ??? Kollektor : ??? Falls jemand digitale Quellen für die Temperaturkurven des NTC 10Kohm kennt, immer her damit ;-).
@Mario Hast du schon negative Temperaturen gemessen ? Hier ist die Temperatur in den letzten Tagen leider nicht unter 0°C gegangen :-/. Kältespray habe ich auch nicht zur Hand ...
Hallo Rudi, wie sind denn die NTC 10kOhm beschaltet? Gegen 5V? Was für Werte benötigst du? 8bit 14bit, 16bit? Martin
Die Beschaltung kenne ich nicht. Ich bekomme nur einen Wert in Form von einem Zeitintervall, der dann in Zusammenhang mit dem Referenzwert die Temperatur darstellt. Da die Temperatur/Werte-Paare stark nicht linear sind, ich habe zum Testen eine Kurve aufgenommen (ohne Referenzwert), bräuchte ich eine mehr oder minder gute Kurve vom NTC, um den Zusammenhang von diesem Refernzwert zu ermitteln. 16Bit für einen Test ist wohl mehr als genug.
Die Temperaturen habe ich jetzt per Messung bestimmt, wie der Referenzwert in die Messung eingeht ist jetzt auch klar. Ich bau einen Adapter für den Bus auf RS232/TTL mit Opto und einem AVR644er als Sklaven. Die Platine kann an das Kabel angezapft oder per zweitem Kabel direkt eingeschliffen werden. Folgende Daten werden erkannt bzw. können dann geändert werden: EEProm per I2C (wie die Steckkarte, Werte sind noch nicht bekannt), alle Temperaturen und der Status der Relais und die bisher unbekannten Pins. Die Daten können dann per RS232 gelesen oder geschrieben werden (wenn bekannt), die Software dann als OS. Die Platine wird etwa 6x6cm groß. Evtl. auch einen Tick größer. Falls Interesse besteht, würde ich mehrere Platinen fertigen lassen.
Update zur Platine: Die Platine wird jetzt erstmal nur eine Möglichkeit zur Adaption bieten. Das Flachbandkabel muss von der Displayeinheit gelöst werden und die Platine wird direkt auf den Stecker von der Displayeinheit gesteckt, das Kabel dann direkt auf die Platine. Der 644er wird erstmal mit den internen 8MHz laufen, ein externes Quarz wird vorgesehen (falls es Probleme mit der UART geben sollte). Dann noch ein 32KHz Quarz für den Timer. Reset-Taster, 3 LED, Programmieradapter (6 Pol) und eine Klemmleiste für die UART über den OPTO (RX,TX,VCC,GND). Die gefundenen Inputs können durch Widerstände vom Bustreiber getrennt und direkt als Inputs genutzt werden (wenn nötig). Der 644er ist dann auch am Ende der möglichen Verdrahtung.
@rudi Außensensor an EMS: zum Glück waren nur ganz kurz Minusgrade (ich warte nicht wirklich darauf). Hat aber gereicht, um zu sehen, dass die negativen Temperaturen von 0xFFFF rückwärts gerechnet werden 0xFFFF entspricht -0,1 Grad, 0xFFFE -0,2 Grad usw. Ich schlage mich gerade mit der Bereitstellung der Daten im Webserver herum, damit mein Internet Tablet (Nokia N770) die Daten aktuell anzeigt. Das Nokia soll mein Hausdisplay werden (gab es günstig bei Ebay). Es macht aber noch Probleme bei AJAX bzw. Javascript. Aber der Winter ist ja noch lang. Tschau, Mario
Angehängte Dateien:
-
heiz.png
4 KB
@Mario > herum, damit mein Internet Tablet (Nokia N770) die Daten aktuell > anzeigt. Auch eine Idee ;-) Zur 2107: Die ersten Daten sind heute eingeflogen ;-) Anbei eine Grafik von den Temperaturen und den Relais direkt vom Bus ...
Ich suche schon lange nach einer Möglichkeit die Istdaten meiner GB162 in meiner Linux-Haussteuerung auszuwerten. Nach dem Lesen des Threads bin ich total begeistert :-) Ich plane, den EMS-Bus mit einem Net-Io (Ethernet-AVR von Pollin) mitzulesen. Die aktuellen Daten würde ich dann per Modbus über Ethernet der Linuxsteuerung zur Verfügung stellen. Falls Interesse besteht würde ich den Sourcecode natürlich auch gern weitergeben. Eine Frage hätte ich zum Interface (Pegelwandler), gibt es da zum Schaltplan (oben im Thread) auch eine Bestückungsliste mit richtiger Dimensionierung der Bauelemente bzw. einen aktualisierten Schaltplan? Grüsse Matthias
Hallo Matthias, so etwas in der Art wollte ich auch aufbauen. Hatte aber bisher noch keine Zeit hierfür. Wenn Du bereit wärst den Quellcode weiterzugeben, wäre es toll. Viele Grüße Gerhard
> Eine Frage hätte ich zum Interface (Pegelwandler), gibt es da zum > Schaltplan (oben im Thread) auch eine Bestückungsliste mit richtiger > Dimensionierung der Bauelemente bzw. einen aktualisierten Schaltplan? Nein, der IC wird als reiner Komparator benutzt, der Rest ist Hysterese und Überspannungsschutz.
@ Gerhard: Das mit der Zeit ist auch immer mein Problem... Prinzipiell habe ich schon früher mal die WebServer-Software von Ulrich Radig genommen, Sachen, die ich nicht brauche entfernt und eine ModBus-Schnittstelle (Code für uCLinux stammte auch aus dem Web) eingebaut. Fehlt also nur noch das EMS-Interface, aber da gibt's im Thread ja auch schon ein Beispiel für den Atmel. Da also der verwendete Code auf der Arbeit anderer basiert geb' ich das fertige Projekt natürlich auch gern weiter. @Rudi >Nein, der IC wird als reiner Komparator benutzt, der Rest ist Hysterese >und Überspannungsschutz. Hättest Du ein Problem damit mir die Stückliste deines Aufbaus zukommen zu lassen? Ich kenne mich nämlich eher in Software fit und für die Hardware müsste ich mich erst noch tiefer mit der Materie befassen, da ich meine Heizung ja nicht schrotten will..... Falls Du das nicht über das Forum machen willst. meine eMail ist matthias punkt bartsch at gmx punkt net. Viele Grüsse Matthias
Angehängte Dateien:
-
2107.png
16 KB
@Matthias R_ESD, D_ESD und R_HYST habe ich nicht bestückt. Der Rest sollte benutzt werden.
Nachtrag: Der Bus ist dann nach wie vor ungeschützt. Ein Komparator mit Opto wäre ideal, ich habe zwar die Bauteile, bin aber noch nicht zu einem Testaufbau gekommen ...
Hallo Rudi, ganz vielen Dank für den Schaltplan. Da kann ich mich ja sobald als möglich an's Basteln machen. Einen Optokoppler werde ich mir wahrscheinlich aber noch gönnen... Grüsse und nochmals vielen Dank Matthias @all Oben im Thread ist ja das Protokoll auf dem EMS-Bus beschrieben, soweit ich gesehen habe als Phyton Programm. Ich will den Phyton-Code in eine C-Library portieren. Oder hat das schon jemand gemacht und ich hab es nur überlesen?
@Matthias EMS: ich denke, eine Library gibt es noch nicht. Rudi hat seine Auswertung in Phyton, ich in Delphi erstellt. Da ich jetzt alle interessanten Werte aus der Heizung habe, tut es das für mich erstmal;-) Zum Thema Optokoppler: ganz so kritisch würde ich das nicht sehen. Der EMS-Bus ist ja zur Vernetzung der Heizungskomponenten im ganzen Haus gebaut und dürfte daher ziemlich resistent gegen äußere Einflüsse sein. Im Zweifelsfall bricht halt die Kommunikation zusammen und geht nach Störungsbeseitigung wieder. Der Bus muss schließlich heizungsbauerkompatibel sein ;-) Die Entscheidung muss natürlich jeder selbst treffen. No Risk, No Fun. bye, Mario
Hallo an Alle Habe mich inzwischen von meinem PIC verabschiedet und habe mir ein ATmega8 Entwicklungskit mit USB-Prog enscheiden mit dem man auch andere Microcontroller programmieren kann. Habe den C-Quelltext von Rudi übernehmen können und fast ohne Änderungen übernehmen können. Auch wenn ich nicht wirklich verstehe was der Quelletext eigentlich wirklich macht ;-) Auf der Platine ist ein Max RS232-Chip den ich einfach über ein Kabel an den Service-Key angeschlossen habe. Funktioniert erst mal fürs erste. Nur gibt es noch Probleme mit dem Java-programm die ich nicht wirklich in den Griff bekomme. Irgendwie bekomme ich sämtliche Daten nur nach dem ich den COM-Port schließe. vorher scheine ich keine Daten zu bekommen. Würde ja auch gerne mit Python mithelfen. Allerdings habe ich echt keinen Bock mich jetzt Tage/Nächtelang erst mal in Phyton, MySQL oder andere Datenbank und GNU-Plot zu beschäftigen. @All fände es auch gut wenn nicht jeder sein eigenes Süppchen kocht. Mein Versuch das zu ändern ist ja wohl fehlgeschlagen... Jetzt hätten wir Rudi mit Phyton, Mario mit Delphi, ich mit Java und jetzt kommt noch C dazu... ;-) @Rudi würdest Du mir/uns vielleicht Dein Script zur Verfügung stellen? Dazu müsste ich auch wissen welche Datenbank dazu installieren müsste. Das GNUPlot-Script wäre vielleicht auch interessant. @Matthias Wäre auch an einer gemeinsamen Hardware interessiert und auch an dem Quelltext. Leider habe ich kaum den Quelltext fur den ATMega verstanden und wäre vermutlich keine große Hilfe bei der Software. Würde auch noch mal für das AVR-Board von Pollin geld ausgeben. Auch wenn ich für dieses Projekt am Ende mehr Geld ausgegeben habe als für die Original Hardware von Buderus. Allerdings wäre es schön wenn man nicht unbedingt auf Linux angewiesen wäre und auch mit Windows auf dem PC lassen könnte. Wäre natürlich noch besser wenn man eine SD-Karte hätte die die Daten solange zwischenspeichert bis man den PC hochfährt und nicht unbedingt einen Server mitlaufen lassen muss. Das hätte den Vorteil dass man die Daten auch weiterhin aufzeichnen kann wenn man aus irgendwelchen Gründen der Server mal neugestartet wird. *Könnte gerne bei der Decodierung mithelfen, auch wenn es schon so aussieht ob schon alle Telegramme komplett entschlüsselt sind. *Könnte auch gerne Adapterplatinen entwickeln auf der dann der "Telegrammumwandler" sitzt und eine SD-KKarte platz findet. Mir wäre dann aber auch wichtig dass auf der Platine eine Sendefunktion untergebracht werden kann. Nachdem das loggen funktioniert will ich auf jeden fall auch vom PC, Server, Controllerplatine oder was auch immer Die Heizungsprogramme ändern kann. Vielleicht sogar automatisiert für Feiertage und Urlaubstage für das ganze Jahr im Vorraus. Aber bis dahin ist es wohl noch ein längerer Weg.... Gruß Ingo
@IngoF > fände es auch gut wenn nicht jeder sein eigenes Süppchen kocht. Mein > Versuch das zu ändern ist ja wohl fehlgeschlagen... Jein, bisher verwenden wir mysql und gnuplot (in ajax gibt es ja auch schon etwas) für die Visualisierung. Wie die Daten in die Datenbank gelangen ist bisher das "Süppchen". Ich kann meinen suboptimalen Aufbau kurz beschreiben: Heizung -(EMS)-> Mega8 -(RS232)-> CORTEX -(RS232/USB)-> Laptop -> Parser (python) -> Binary-Log/Sqlite-DB -(Network upload)-> Server -> Mysql -> Gnuplot -> Web So sieht es bei mir aus ;-) > würdest Du mir/uns vielleicht Dein Script zur Verfügung stellen? Dazu > müsste ich auch wissen welche Datenbank dazu installieren müsste. Das > GNUPlot-Script wäre vielleicht auch interessant. Das Skript kann bisher nicht alle Daten parsen. Ich kann die beiden mal posten. Die Konvertierung nach Sqlite will ich da nicht drin haben, da das mit einem kleinen Netz-Controller nicht funktioniert. Ich bin leider bei mir, wegen der 2107, nicht viel weiter gekommen. > Allerdings wäre es schön wenn man nicht unbedingt auf Linux angewiesen > wäre und auch mit Windows auf dem PC lassen könnte. Wäre natürlich noch > besser wenn man eine SD-Karte hätte die die Daten solange Ja, ich werde demnächst den Kram auch auf einem Windos PC installieren. Ab dem Netzwerkkontroller soll das dann identisch zu meiner Installation (etwas verbessert) laufen, aber eben auf Windos. Die Adaption zur Heizung ist komplett anders (leider). Die Tools für die Visualisierung sind für mehrere Platformen verfügbar. Wir bräuchten einen kleinen Webserver der die Daten empfangen/quittieren kann und in die Datenbank schreibt und/oder ein kleines Programm welches die Daten abholt. Ich würde schon wegen der Platformunabhängigkeit und der Wartung kein C benutzen wollen, ich komme übrigens aus der C/C++-Ecke. > Mir wäre dann aber auch wichtig dass auf der Platine eine Sendefunktion > untergebracht werden kann. Nachdem das loggen funktioniert will ich auf > jeden fall auch vom PC, Server, Controllerplatine oder was auch immer Mach das ! Du hast 12V/GND und das Signal. Das Signal liegt bei +- 2.5V auf den 12V (9600 Baud). Eingang dann vom uC mit 3.3V oder 5V. Wenn du daran arbeiten könntest wäre das super ! Das Hauptproblem bei Senden ist die CRC. Im schlimmsten Fall muss man den String 256 mal senden ...
Hallo, will mich nochmal zu Wort melden bzgl. meiner Vorstellung mit dem Pollin-Board. Vorteil sind die geringen Hardwarekosten (ca. 20€ als Bausatz bzw. knapp 30€ für das Fertiggerät). Die Busanschaltung muss man dann natürlich noch selber basteln. Für das Board sind schon viele fertige Projekte im Netz zu finden, mit denen man ohne grossen Entwicklungsaufwand eine gute Software-System-Grundlage hat. Implementiert man darauf das EMS-Protokoll hat man mit geringen Kosten eine netzwerkfähige Schnittstelle zur Heizung (seriell könnte das Board auch). Implementiert man jetzt hier drauf das Modbus-Protokoll, kann man die Kiste neben Linux und Windows z.B. auch mit einem Wago-Ethernetcontroller (Wago System 750) auslesen. Prinzipiell könnte ich mir als Interface natürlich auch andere Hardware vorstellen, aber nach meiner Erfahrung ist es oft so, das wenn man noch viel neu entwickeln muss ein Projekt oft einschläft. Zweifelsohne wäre aber ein SD-Interface praktsch, wenn man keinen Server ständig am Laufen hat. Vielleicht sollte man im ersten Schritt aber mal alle Infos in einem Wiki o.ä. sammeln. Dann könnte man sich besser orientieren was es schon gibt. Ich habe zwar noch nie ein Wiki aufgesetzt aber ich könnte mir mal ansehen wie das geht. Denn auf die Dauer wird der Thread schon ziemlich unübersichtlich.
@Werner Brösel, nöhh, hab keine Lust am hijacken. Macht ja im Endeffekt nur Arbeit. Für meine privaten Zwecke komme ich mit den Infos hier gut klar. Ich könnte also auch nur schnorren und mich an der Arbeit anderer bedienen, ohne was beizutragen..
@Matthias > Ich könnte also auch nur schnorren und mich an der Arbeit anderer > bedienen, ohne was beizutragen.. Was hast Du dir vorgestellt ? Für eine Wiki kann ich mich nicht begeistern, man findet nichts wieder und es gibt irgendwie keine gescheite Übersicht der Artikel. Wenn wir einen zentralen Ort anlegen, dann für alle. Doku, Software und ein Forum/Mailinglist für Hilfe und Austausch, von der möglichen B.-Kontra abgesehen ;-) Evtl. können sich die stillen Mitleser dazu äußern ...
@Rudi >Was hast Du dir vorgestellt ? Für eine Wiki kann ich mich nicht >begeistern, man findet nichts wieder und es gibt irgendwie keine >gescheite Übersicht der Artikel. Beim Suchen nach einer Schnittstellenbibliothek für Buderus bin ich auf ein Projekt für Viessmann-Geräte gestossen (http://openv.wikispaces.com) Etwas in der Art fände ich praktisch... Zumal ja jeder etwas andere Bedürfnisse/Infrastruktur hat und da könnte man übersichtlich die einzelnen Lösungen sortieren.
@Matthias > Beim Suchen nach einer Schnittstellenbibliothek für Buderus bin ich auf > ein Projekt für Viessmann-Geräte gestossen (http://openv.wikispaces.com) > Etwas in der Art fände ich praktisch... Zumal ja jeder etwas andere > Bedürfnisse/Infrastruktur hat und da könnte man übersichtlich die > einzelnen Lösungen sortieren. Also eher ein CMS als ein Wiki. Die Sourcen und Programme sind bei denen nicht auf der gleichen Domain. Ich würde ein Projekt auf Sourceforge anlegen, Webseite, Sourceverwaltung, Mailingliste ... . Für die Webseite könnte ich mir (bitte nicht schlagen;-)) joomla vorstellen und dann über die Userverwaltung das Editieren erledigen. Am Ende sind es eh nur eine Hand voll Leute die aktiv etwas tun. Siehe hier ;-)
>Ich würde ein Projekt auf Sourceforge anlegen, Webseite, >Sourceverwaltung, Mailingliste ... . Für die Webseite könnte ich mir >(bitte nicht schlagen;-)) joomla vorstellen und dann über die >Userverwaltung das Editieren erledigen. @Rudi Ok, wollen wir es mal angehen? Die Webseite ja keinen Schönheitspreis gewinnen, Hauptsache man strukturiert die vielen Infos mal. Vielleicht kannst Du initial die Seite anlegen, Du hast ja auch am meisten zu dem Projekt beigetragen. Damit keinn Hijacker-Verdacht aufkommt.... Habe mir gestern aus dem Thread mal die Protokoll-Infos zusammengesucht, die ich für die Anbindung brauche. Ich schreib jetzt das sowieso mal für mich zusammen. Post wenn ich fertig bin mal meine Zusammenfassung.
Hallo, lese auch bei Euch mit, obwohl ich eine Ecomatic 4000 habe ... beim Aufbau der Seite mit Joomla! kann ich Euch gerne ein wenig unterstützen. Gruß, Mike Buderus HS2401 / Ecomatic 4000 (mit Schieberegler) / Baujahr 1994 ATMEL ATMEGA32, Pollin AVR Net I/O, EvalBoard 2.0.1 / AddOn Board
Hatte mal eine XLS-Tabelle gemacht mit den damaligen Erkenntnissen. Vielleicht könnte man die so oder anders weiterführen. Gruß Ingo
@Ingo: Vielen Dank für die Tabelle. Habe Sie mal mit den anderen Infos abgeglichen und ergänzt. Muss ich noch weiterbearbeiten, aber mal als Zwischenstand für alle. Gruss Matthias
Angehängte Dateien:
-
del.png
87 KB
Was haltet ihr von diesem Aufbau für die Beschreibung (siehe Anhang) ? Ich habe die Seite mit Tex erstellt.
@Rudi sieht sehr gut aus. Wie sehen denn die Dokumentation aus wenn einzelne Bits eine bestimmte Bedeutung haben? Allerdings müsste man dafür TEX installieren um es zu bearbeiten. Oder ist das ein Format dass man mit OpenOffice oder anderen Programmen öffnen könnte? Warum kein Dateiformat wofür man kein spezielles Programm für benötigt? Kann man die Datei denn auf der Webseite (Joomla) bearbeiten und automatisiert aus der Datenbank erstellen? Glaub mit Joomla kann man ja auch automatisiert PDF Dateien erstellen, oder? Gruß Ingo
> sieht sehr gut aus. Wie sehen denn die Dokumentation aus wenn einzelne > Bits eine bestimmte Bedeutung haben? Das könnte man da problemlos einbauen, z.B etwas eingerückt. > Allerdings müsste man dafür TEX installieren um es zu bearbeiten. Oder > ist das ein Format dass man mit OpenOffice oder anderen Programmen > öffnen könnte? Das Tex-Quell-Format ist reiner Text ;-). Okay, die Syntax ist etwas anders. Du kannst den auch mit Edit öffnen, um aber ein formatiertes Dokument zu erstellen brauchst du Tex. In meinem Fall habe ich es in eine PDF-Datei gewandelt. Das gute daran, du kannst den "Quelltext" in GIT oder was auch immer verwalten und Änderungen verfolgen. > Warum kein Dateiformat wofür man kein spezielles Programm für benötigt? Ich finde PDF schon als normales Format, es ist allerdings nur der Output. > Kann man die Datei denn auf der Webseite (Joomla) bearbeiten und > automatisiert aus der Datenbank erstellen? Glaub mit Joomla kann man ja > auch automatisiert PDF Dateien erstellen, oder? Nein, das wäre mit viel Aufwand verbunden. Das mit dem Bild war auch nur ein Vorschlag wie man es machen könnte.
Angehängte Dateien:
-
lp2107.png
370 KB
Zur 2107: Ich habe die Adapterplatine jetzt fertig und werde die nächsten Tage mal berichten.
Hallo! bin leider erst jetzt auf diesen Thread gestoßen. Ich habe ein KM271 bei mir in Betrieb, an einer Logamatic 2105 (wie 2107, nur ohne Solarmodul-Nachrüstmöglichkeit) mit Warmwasserbereitung. Ich habe auch die Software und mittels Serial-Logger das Protokoll zum Teil ermittelt. Eine Beschreibung findet Ihr im Anhang. Im Moment kenne ich nur den Log-Modus, kann also nur die laufenden Meldungen der Heizung interpretieren, aber keine Änderungen an der Konfiguration vornehmen. Dazu müsste ich mal wieder die Windows-Software von Buderus laufen lassen und mitprotokollieren. Das KM271 könnte ich bei Gelegenheit ausbauen und fotografieren damit man die Bauteile und Verbindungen bestimmen kann, aber das kann ich erst am Wochenende. Schreibt mal, ob das Protokoll der KM-271 hilft bei Eurem Ansatz. Himtronics
@Joachim König Das sind doch mal ein paar Daten. Sind die evtl. auch dort beschrieben: Beitrag "Re: Logamatic 2107 Schnittstelle" Das KM271-Modul setzt die RS232 auf I2C um und vice versa. Das Display-Modul fragt eine I2C-Adresse ab, die evtl. ohne Solar oder KM271 nicht auf dem Bus vorhanden ist '(Beide benutzen wohl die gleiche Adresse). Ich konnte die Displayeinheit aber nicht zur Kommunikation überreden, bzw. habe dort auch nicht weiter geforscht, da die Daten auch direkt abgegriffen werden können, mit direktem Zugriff auf das EEProm (I2C). Viele Daten können eigentlich nur im EEProm gespeichert werden, den Aufbau der Daten zu finden ist mit einem KM271 mit Sicherheit viel einfacher ... Einige Bilder mit erkennbaren IC Bezeichnungen und Leiterbahnen wären super ! Einige Fragen habe ich noch: Was ist die Pumpenleistung ? Braucht man für die Steuerung ein extra Modul ? Was sind das für Werte: Brennereinschalttemperatur/Brennerausschalttemperatur ??? Welche Temperaturen werden dort gemessen ?
@Rudi schrieb: > Was sind das für Werte: > Brennereinschalttemperatur/Brennerausschalttemperatur ??? Welche > Temperaturen werden dort gemessen ? das sind keine Messwerte sondern die Temperatur, bei der der Brenner ein- beziehungsweise ausschaltet. Die ist abhängig von der Aussentemperatur, dem Gebäudetyp etc, also wenn's draußen kalt ist, soll das Wasser im Kessel heißer sein als wenn's lau ist, insbesondere wenn kein Mischer vorhanden ist. So ähnlich jedenfalls.
Angehängte Dateien:
-
ems.png
24 KB
Hallo, habe es endlich geschafft Ein Java-Programm zum laufen zu bekommen. Es werden nur Telegramme mit Daten mitgeloggt. Man muss den PC mit dem Sklaven verbinden der das Break erkennt und einen Rahmen um die Daten setzt. Dannach noch die richtige Schnittstelle auswählen und 'Verbinden' drücken. Wenn Java installiert ist muss man nur das ZIP entpacken und emslog.jar oder emslog.bat mit doppelklick starten. Wenn man EMSlog schließt ohne vorher auf 'Verbinden' zu klicken muss man EMSlog mit dem TaskManager beenden. Es gibt noch unter bestimmten Bedingungen Lesefehler auftreten. Sonst kann das Programm noch garnichts. Jetzt kann ich endlich mit der Programmierung anfangen ;-) Für die Mitleser die keine Hardware zum Testen haben können sich ja das Screenschot ansehen. Gruß Ingo
Angehängte Dateien:
-
CIMG2401.JPG
1,2 MB -
CIMG2405.JPG
1,1 MB
So, hier mal 2 Bilder des KM271. Als Chip ist ein Sipex SP232 ACT 9524 drauf, und ein paar Kondensatoren, Widerstände, eine Diode. Joachim
Sehr schön. Also gibt es doch noch 2 Leitungen für eine UART auf dem Bus. Empfängst du, auch ohne den Logmodus zu aktivieren, Daten auf der UART ? Wird dort zufällig zyklisch etwas gesendet ?
Rudi schrieb: > Sehr schön. Also gibt es doch noch 2 Leitungen für eine UART auf dem > Bus. > Empfängst du, auch ohne den Logmodus zu aktivieren, Daten auf der UART ? > Wird dort zufällig zyklisch etwas gesendet ? Nein, da ist Ruhe. Werde mir bei Gelegenheit mal das Protokoll ansehen für das Ändern der Konfiguration. Die Konfiguration die am Anfang nach dem Aktivieren des Protokoll-Modus gesendet wird, kann ich schon zum Teil interpretieren, z.B. die Zeiten für die Heizphasen.
Hallo Rudi, kannst Du mir ein wenig über die Struktur Deiner mySQL-Datenbank geben? Wie hast Du die angelegt? Pro Telegramm eine Tabelle? Die unterschiedlichen Telegramme kommen ja zu unterschiedlichen Zeit und natürlich unterschiedlich oft. Belegen eigentlich nicht benutzte Werte Speicherplatz? Denke schon. Was für Datenformate hast Du verwendet. Hätte nie gedachte dass es soooooooo viele Datenformate geben kann. Bei der Datenbank soll ja nicht wirklich unütz Platz verschwendet werden. Gruß Ingo
noch vergessen.... Wie groß ist denn Deine Datenbank mit Werten für einen Monat? Gruß Ingo
Angehängte Dateien:
-
del1.png
16 KB
@IngoF Ich speicher keine Datensätze von der Anlage in der Datenbank. Die Logdateien belaufen sich in etwa auf 10GB über gefühlte 3 Monate. In der Datenbank werden nur relevante Daten gespeichert. Temperaturen, Brenner, Gaszähler usw.. Ich habe bisher 2.5M Einträge vom Juli an. Der Durchschnitt ist im Laufe der Zeit durch Optimierung aber weniger geworden. Der Aufbau der Datenbank ist für eine Query nicht optimal, aber ich sehe erstmal nichts einfacheres. Es gibt eine Tabelle mit IDs der Sensoren und die Datentabelle. SOURCE-TABLE:
1 | CREATE TABLE `SOURCE` ( |
2 | `ID` int(11) NOT NULL auto_increment, |
3 | `ADDR` char(200) NOT NULL, |
4 | PRIMARY KEY (`ID`), |
5 | KEY `ADDR` (`ADDR`) |
6 | ) ENGINE=MyISAM AUTO_INCREMENT=0 DEFAULT CHARSET=utf8 ROW_FORMAT=DYNAMIC |
Die ADDR ist bei mir der MAC angelehnt, z.B. 00:12:33:12:21:55:45:45 oder auch HE:IZ:00:00:00:00:00:01. Da ich mehrere Sensoren habe, und es auch mehr werden sollen, ist das erstmal für mich wichtig die Daten nach dem Absender zu unterscheiden. Die Datentabelle ist dann nicht sooo optimal, hält sich aber in Grenzen:
1 | CREATE TABLE `DATA` ( |
2 | `ID` int(10) unsigned NOT NULL auto_increment, |
3 | `SOURCE` int(11) NOT NULL, |
4 | `TYPE` int(10) unsigned NOT NULL, |
5 | `DATA` char(200) NOT NULL, |
6 | `TIME` datetime NOT NULL, |
7 | PRIMARY KEY (`ID`), |
8 | KEY `SOURCE_TYPE_TIME` (`SOURCE`,`TYPE`,`TIME`), |
9 | KEY `SOURCE` (`SOURCE`), |
10 | KEY `TYPE` (`TYPE`), |
11 | KEY `TIME` (`TIME`) |
12 | ) ENGINE=MyISAM AUTO_INCREMENT=0 DEFAULT CHARSET=utf8 PACK_KEYS=1 ROW_FORMAT=DYNAMIC |
Bei der Tabelle: SOURCE : Source-ID aus der Tabelle SOURCE TYPE: Typ der Daten, kann für jeden Sensor selbst festgelegt werden DATA: die Daten TIME: UTC Zeitstempel
>Ich speicher keine Datensätze von der Anlage in der Datenbank. Die >Logdateien belaufen sich in etwa auf 10GB über gefühlte 3 Monate. > >In der Datenbank werden nur relevante Daten gespeichert. Temperaturen, >Brenner, Gaszähler usw.. Da hast Du mich falsch verstanden. Natürlich wollte ich auch keine unnützen Daten speichern. ------------------------------------------------------------------------ -- Mal angenommen jedes Telegramm hätte 22Byte. Das Telegramm 0815 kommt alle 10 Sekunden und hat 10 Temperaturen (0815=2 +10*2 pro Temperatur). Das Telegramm 4711 kommt jede Sekunde und hat eine Temperatur. (4711=2Byte +1*2Byte für Temperatur +18Byte noch unbekannt). Ich hatte jetzt gedacht: eine Tabelle für Telegramm 0815 mit 10 Spalte/Werten und 6 Einträgen pro Minute. Die zweite Tabelle für Telegramm 4711 mit einer Spalte/Wert und 60 Einträgen pro Minute. ------------------------------------------------------------------------ -- Also hätte man hinterher 2 Tabellen mit etwa 60Byte pro Minute. > `DATA` char(200) NOT NULL, Sorry, aber bin noch nicht soweit mit mySQL... Ich hoffe nicht dass für jeden Sensor mit 200 Zeichen gespeichert wird. Gruß Ingo
> > `DATA` char(200) NOT NULL, > Sorry, aber bin noch nicht soweit mit mySQL... Ich hoffe nicht dass für > jeden Sensor mit 200 Zeichen gespeichert wird. Doch, aber dafür gibt es dann: PACK_KEYS=1 ROW_FORMAT=DYNAMIC ;-) Ich wollte erst ein float, aber evtl. kommen doch noch andere Daten. > Ich hatte jetzt gedacht: > eine Tabelle für Telegramm 0815 mit 10 Spalte/Werten und 6 Einträgen pro > Minute. > Die zweite Tabelle für Telegramm 4711 mit einer Spalte/Wert und 60 > Einträgen pro Minute. Wenn du keine Daten verlieren willst kannst du es so machen. Im Zweifelsfall einfach eine Tabelle anlegen und mit Pseudodaten füllen und schauen wie groß die Tabelle etwa wird. Das füllen der Tabelle ist nicht das Problem. Die Abfragen für die Grafik usw. sind bei vielen Daten sehr CPU lastig. Speicherplatz ist eigentlich kein Problem.
@Joachim K. > Nein, da ist Ruhe. Werde mir bei Gelegenheit mal das Protokoll > ansehen für das Ändern der Konfiguration. Die Konfiguration > die am Anfang nach dem Aktivieren des Protokoll-Modus gesendet > wird, kann ich schon zum Teil interpretieren, z.B. die Zeiten für > die Heizphasen. Ich konnte es mehr oder weniger verifizieren. Ohne eingesteckte Platine lässt sich der Modus nicht aktivieren. Bei erkanntem/eingeschaltetem zweiten Heizkreis werden dort andere Daten gesendet und es wird nicht auf 0x02 oder 0x10 geantwortet.
Moin allerseits, ich hänge mich hier mal mit dran, da ich schon ne Weile mitlese ... Wir haben eine GB142 mit ner RC35. Das Ganze Projekt klingt recht spannend, aber einiges habe ich noch nicht verstanden. Es sind 2 unterschiedliche Systeme, ja? Einmal die Logamatic2107 und einmal die RC30/35 Serie, wobei aber beide Systeme das gleiche Protokoll haben? Technische Möglichkeiten wie Oszi stehen mir leider nicht zur Verfügung, daher könnte ich höchstens versuchen bei der weiteren Entschlüsselung zu helfen!? Benötigt wird also der Klinkenstecker für die RC3x und dann eine kleine Platine zur Umsetzung. Bei mir läuft eh ein Homeserver 24/7 , auf dem die Daten dann verarbeitet werden könnten. SQL ist ebenfalls vorhanden. Das Signal kann man dann einfach über die RS232 Schnittstelle im PC verwerten oder wird noch weiteres benötigt wie z.B. ein µC zur Umsetzung des Datenstroms auf der Platine und dann erst die Kommunikation zum PC? Gruß Jens
Unter Beitrag "eBus CRC Berechnung nachvollziehen" wird über den eBus diskutiert. Der EMS-Bus scheint dem eBus ja sehr ähnlich. Unter http://www.mikrocontroller.net/attachment/54958/eBUS_Stuttgart_041201_eBUS_Only.PDF ist auf S.28 ein eBus Interface dargestellt. Würde das auch für den EMS-Bus gehen? (vielleicht nicht unbedingt 24V Versorgung) Was meint ihr dazu? Gruss Matthias
@Jens H. > Es sind 2 unterschiedliche Systeme, ja? Ja. > Einmal die Logamatic2107 und einmal die RC30/35 Serie, wobei aber beide > Systeme das gleiche Protokoll haben? Nein. > Technische Möglichkeiten wie Oszi stehen mir leider nicht zur Verfügung, > daher könnte ich höchstens versuchen bei der weiteren Entschlüsselung zu > helfen!? Ja, die CRC ist bei der RC30/35 noch nicht ganz klar. > Benötigt wird also der Klinkenstecker für die RC3x und dann eine kleine > Platine zur Umsetzung. Ja. > Das Signal kann man dann einfach über die RS232 Schnittstelle im PC > verwerten oder wird noch weiteres benötigt wie z.B. ein µC zur Umsetzung > des Datenstroms auf der Platine und dann erst die Kommunikation zum PC? Ein uC vor dem PC ist besser, siehe oben die Posts.
@Matthias: > Unter Beitrag "eBus CRC Berechnung nachvollziehen" wird über den eBus > diskutiert. Der EMS-Bus scheint dem eBus ja sehr ähnlich. > Unter > http://www.mikrocontroller.net/attachment/54958/eB... > ist auf S.28 ein eBus Interface dargestellt. Würde das auch für den > EMS-Bus gehen? (vielleicht nicht unbedingt 24V Versorgung) Was meint ihr > dazu? Könnte funktionieren. Musste man aber auf 12V auslegen. Evtl. sind die 9600 Baud zu schnell, muesste man mal aufbauen und messen.
Hallo Rudi, danke für die Antworten! Ein µC davor ist besser, aber nicht zwingend notwendig oder wird auf jeden Fall benötigt? Oder hängt das von der verwendeten Software auf dem Rechner ab? Ich war mir sicher das mit dem µC gelesen zu haben, habe es aber vorhin nicht wiedergefunden und deswegen gefragt ;-) Die main.c von Mario hab ich gefunden, aber leider noch kein Schaltbild um eine Platine aufzusetzen. Wobei ihr ja scheinbar unterschiedliche Versionen einsetzt, da Mario mit nem Mega128 arbeitet und du nen Mega8 einsetzt. Magst du vielleicht das Layout preis geben? @Matthias: Falls die eBus Platine funktionieren sollte, wäre das natürlich auch noch ne Möglichkeit ;-) Sorry für die vielleicht blöde Frage, aber direkt von Buderus gibt es ja noch ein RS232 Gateway für die aktuellen Thermen, das ist aber nicht die Logamatic 2107 Schnittstelle oder doch? Gruß Jens
@ Jens H. > danke für die Antworten! Ein µC davor ist besser, aber nicht zwingend > notwendig oder wird auf jeden Fall benötigt? Oder hängt das von der > verwendeten Software auf dem Rechner ab? Ein PC ist zu langsam bzw. hat kein Realtime. Also uC und fertig. > aber leider noch kein Schaltbild > um eine Platine aufzusetzen. Wobei ihr ja scheinbar unterschiedliche > Versionen einsetzt, da Mario mit nem Mega128 arbeitet und du nen Mega8 > einsetzt. > Magst du vielleicht das Layout preis geben? Ein Mega8 und dann VCC/GND RX/TX, also nichts kompliziertes was unbedingt ein Layout erfordert. Fertige Eval. Boards gibts ja wie Sand am Meer.
Also ich habe auch den ATmega8. Habe mir ein Komplettkit mit USBprog fur etwa 69 Euro gekauft. Ist alles drin was man zur Programmierung für den Atmega8 braucht. Am Service-key gibt es zwei Kontakte die das Signal mit +-2,5Volt haben. Diese habe ich einfach ohne weitere Technik auf den RX-Eingang des Atmega8 gelegt. Der Quellcode für den ATmega8 wurde hier schon von Rudi gepostet. Den PC schließt man am TX-Ausgang des Atmega8 an. Bisher läuft es nur am Service-Key direkt. Wenn man die Platine am Bus anschließen will benötigt man auf jeden Falle ein Schaltung die ich mir auch noch zulegen werde. Ich habe es schon, mit Hilfe von Rudi geschafft ein Java-Programm zu schreiben dass die Daten mittloggt und in der MySQL-Datenbank abspeichert. Wenn die letzten Fehler weg sind werde ich hier gerne den Download-Link posten. Die Visualisierung kommt natürlich auch noch rein. Vermutlich mit GNUPlot oder direkt im Java-Programm. Gruß Ingo
Hallo ihr zwei, vielen Dank für die Hinweise Da ich KEINEN Service-key habe, muss ich direkt an den Bus. Sehe ich das richtig, das Ingo mit Service-Key arbeitet und Rudi ohne oder auch mit? Denn Ingo schreibt ja ohne Service-Key benötigt man ne Schaltung dafür!? Daher auch meine Frage nach einer passenden Platine ... Denn wenn dafür noch ne Schaltung benötigt wird, dann könnte man die ganze Sache auch auf eine Platine basteln. Gruß Jens
Also an der Service-Key-Buchse gibt es das Bus-Signal mit +-2,5 Volt. Ab Bus (also dort wo die RC30 oder RC35 dran hängt) kommen 12 +-2,5 Volt an und können nicht einfach ohne Schaltung an den ATmega8 angeschlossen werden. Habe nur zwei Brücken auf der Platine eingelegt, ein Adapterkabel ohne Elektronik gebastelt und es hat funktioniert. Habe die CRC-Berechnung noch mal mit dem Generator-Polynom berechnet. Hat laeider nicht funktioniert. Werde mal wenn ich Zeit habe einfach alle möglichen Berechnungen durchlaufen (Startwerte 0x00-0xff, XOR am Ende 0x00-0xff und Generatorpolynome 0x00-0xff) und dann sollte sich das Geheimnis irgendwie lüften lassen. Es ist jedenfalls kein simples XOR oder addierung über alle Werte. Standart CRC-8 funktioniert auch nicht. Aber für das simple mitloggen braucht man erst mal keine CRC. Aber irgendwann möchte ich ja auch mal die Schaltprogramme ändern. spätestens dann geht es nicht ohne CRC-Berechnung. Gruß Ingo
Angehängte Dateien:
-
del.png
7,4 KB
Zur 2107: Anbei die ersten Daten der Platine. Der Anfang (rot) ist noch vom Versuchsaufbau mit einigen Störungen auf den langen Datenleitungen. Was sich die Leitungen eingefangen hatten, wenn der Brenner startet, ist schon nicht schlecht.
@IngoF
> Habe die CRC-Berechnung noch mal mit dem Generator-Polynom berechnet.
Ich habe es auch schon mit Bruteforce versucht. Filter dir einfach mal
eine kurze Nachricht, die sich zyklisch ändert. Am besten das Datum.
Dort sieht man sehr schön wie sich die CRC ändert. Für ein paar dieser
Nachrichten kann die CRC berechnet werden, und für andere wieder nicht.
Sehr komisch die Berechnung.
Ich habe mir diese Nachrichten genommen (etwa 10) und habe dann per
Bruteforce das gemeinsame Polynome/Startwert/XOR-Endwert gesucht. Leider
ohne Erfolg (Fehler nicht ausgeschlossen).
Bin auch gerade dabei. Habe zwei Nachrichten genommen und schreibe gerade eine BatchDatei.... Welchen Teil hast Du denn zur Berechnung eingeschlossen? vielleicht werden die ersten (adress)Bytes ja nicht mit einbezogen. Versuche mich gerade an diesen beiden: 10 88 14 00 03 6e 00 10 89 29 00 01 90 00 Berechne die Checksumme über alles inkl. der Prüfsumme (6e und 90) und ignoriere das break (00). Dann sollte beim richtigen Polynom oder Berechnung 00 als Prüfsumme herauskommen. Gruß Ingo
> Welchen Teil hast Du denn zur Berechnung eingeschlossen? > vielleicht werden die ersten (adress)Bytes ja nicht mit einbezogen. Deswegen habe ich immer den gleichen Nachrichtentyp genommen. Da sollte es bei CRC8 keine Probleme geben, da der Startwert immer gleich ist. > Berechne die Checksumme über alles inkl. der Prüfsumme (6e und 90) und > ignoriere das break (00). Ja. > Dann sollte beim richtigen Polynom oder Berechnung 00 als Prüfsumme > herauskommen. Genau.
@Jens H.: > Daher auch meine Frage nach einer passenden Platine ... Denn wenn dafür > noch ne Schaltung benötigt wird, dann könnte man die ganze Sache auch > auf eine Platine basteln. Ohne Service-Key benötigst du eine kleine Schaltung für den RX. Der MEGA8 wäre dafür geeignet, da man die Kommunikation zur Heizung über eine Software-UART realisieren muesste (Frame-Error). Der MEGA hat ja nur eine UART. ...
Mario schrieb: > @Rudi > heute habe ich Deinen C-Quellcode auf den Atmega128 angepasst und > übersetzt. Als C-Unwissender hatte ich mich ja schon geoutet ;-). > Mir fehlt noch das Verständnis, an welchem Port das TTL-Signal des > EMS-Bus angeschlossen wird. > In Deinem Code sehe ich immer nur, dass auf dem gleichen USART gelesen > und geschrieben wird. Das kann ja aber nicht sein. > Bitte hilf mir auf die Sprünge. > > Danke, > Mario @Rudi als Antwort schriebst du, der Mega8 hat nur einen Usart. An Rx den EMS-Bus und an Tx kommen die Daten raus ???? Dann kannst du aber doch nicht ZUM Bus schreiben ??? Verwirrung ??? Noch `ne Frage: Würdest du das Hex und die Configuration dafür rausrücken? Gruß Helmut
@Helmut Also zur Zeit gibt es nur ein "Interface" zum loggen. Wenn man schreiben will benötigt man entweder einen zweiten UART oder einen zweiten ATMega8. Allerdings müsste man sich noch Gedanken über "Schaltung" machen die auch auf dem selben Bus senden <b>und</b> empfangen kann. Aber darüber kann man sich Gedanken machen wenn die CRC bekannt ist. Ohne die CRC-Berechnung nützt das "senden können" leider ganrichts wenn die Heizung die wegen Übertragungsfehler ignoriert. Und jedes Telegramm evtl. 256 mal zu senden ist auch keine Lösung. Habe gerade ein Batch Datei geschrieben die die CRC-Berechnung für fast alle Parameter die man angeben kann durchführt. Es sind 1048576 Berechnung für die mein PC vermutlich 26 Stunden brauchen wird. Dummerweise wird die LOG-Datei etwa 8MByte groß und muss dann noch nach den richtigen Werten durchsucht werden. Vielleicht hat ja jemand eine Idee oder kann ein auswertescript oder Programm schreiben. jede errechnete CRC steht als Dezimalzahl in einer Zeile mit einem Doppelpunkt als erstes Zeichen. Jeder Block besteht aus 4 Zeilen (4Telegramme). Die Datei muss nach vier gleichen aufeinanderfolgenden CRC-Prüfsummen durchsucht werden. Eventuell reicht schon ein durchsuchen nach vier aufeinander folgenden 0-CRC. Gruß Ingo
Ups.. das war alles nicht für Helmut gedacht.... @Helmut. Der C-Quelltext wurde von Rudi ja schon gepostet. Kann aber auch gerne die HEX-Datei hier hochladen die ich daraus erzeugt habe, falls Rudi nicht schneller ist. Allerdings ist mein PC mit der HEX-Datei gerade mit CRC-Berechnungen beschäftigt und ich muss warten bis er damit fertig ist. Die Datei ist auf der anderen Partition :( @all wer eine Idee hat hier mal eine Kostprobe der CRC-Datei die gerade entsteht:
1 | FE 06 00#------------------------ |
2 | :154 |
3 | :222 |
4 | :24 |
5 | :216 |
6 | 01# |
7 | :89 |
8 | :123 |
9 | :24 |
10 | :27 |
11 | 10# |
12 | :192 |
13 | :226 |
14 | :126 |
15 | :130 |
16 | 11# |
17 | :3 |
18 | :71 |
19 | :126 |
20 | :65 |
21 | |
22 | FF 06 00#------------------------ |
23 | :154 |
24 | :71 |
25 | :216 |
26 | 01# |
27 | :89 |
28 | :123 |
29 | :24 |
30 | :27 |
31 | 10# |
32 | :226 |
33 | :126 |
34 | :124 |
35 | :130 |
36 | 11# |
37 | :39 |
38 | :71 |
39 | :12 |
40 | :65 |
Gruß Ingo
@IngoF Ich habe hier: http://www.nightmare.com/~ryb/code/CrcMoose.py noch ein nettes Skript für die CRC-Berechnung gefunden.
Danke für den hinweis... Aber meine CRC-Berechnung müsste bald fertig sein und das Script wird vermutlich auch nicht schneller als die JAVA-Version sein. Fragt sich nur wie ich das Ergebnis durchforsten soll... Gruß Ingo
Habe für diese Telegramme die CRC berechnet: 108811241829 108811181B52 10881400036e 108929000190 Habe fast alle möglichen Kombinationen berechnen lassen: Polynom: 0x00 bis 0xff Startwert 0x00 bis 0xff Eingabe gespiegelt: true,false Ausgabe gespiegelt: true,false Ein abschließendes XOR habe ich nicht eingegeben weil die Berecnung sonst 280 tage gedauert hätte. Aber wenn man bei den Telegrammen nach gleicher Prüfsumme sucht erübrigt sich ja die Berechnung, oder? Nur das Durchsuchen der Ergebnisse ist nicht ganz sooo einfach. Habe schon mal versucht die vorkommenden Nullen mit Zeilennummer (findstring in DOS) in eine Textdatei zu exportieren. Die Ergebnisse habe ich in Excel geladen und durch Berechnung die vierer Blöcke zu finden (Wert Zeile)-(Wert-Zeile-3). Also sollte als ergebnis 3 für die vierer Blöcke herauskommen. Alle Zeilen mit falschen Ergebnis gelöscht. Dann den Abstand mit Exel errechnet. Dabei kam immer ein Abstand zwischen den Polynomen von 128 oder 256. Also gabe es wenn meine Überlegungen richtig waren nur bei 0x00 und 0x80 zu einem vierer Block mit CRC=0 Demanch wurde keine richtige CRC erkannt oder die CRC würde anschliend noch mal mit XOR verknüpft. Also müsste man nicht nach einem vierer Block 0 suchen sondern nach einem Block mit vier selben CRC. Keine Ahnung wie ich das anstellen könnte. mit Excel kann ich die Ergebnisse natürlich nicht einlesen weil max 64k Zeilen erlaubt sind. Gruß Ingo
Schau dir mal die Betriebsstunden an, So schwer kann die CRC nicht sein ... Wenn sich nur 1 Byte ändert (bei den Betriebsstunden das letzte vor der CRC) funktioniert ein einfaches XOR aller Werte, um den gleichen Wert für alle Nachrichten zu erhalten. Wenn sich das vorletze Byte ändert, dann sieht es ein wenig anders aus, scheint dann ein etwas anderes XOR zu sein (bit shuffle etc.). Mal ein Beispiel: 08 10 14 00 1A 7C D8 11 : A3 08 10 14 00 1A 7C DA 13 : A3 08 10 14 00 1A 7C DC 15 : A3 08 10 14 00 1A 7C DE 17 : A3 08 10 14 00 1A 7C E0 29 : A3 08 10 14 00 1A 7C E2 2B : A3 08 10 14 00 1A 7C E4 2D : A3 08 10 14 00 1A 7C E6 2F : A3 08 10 14 00 1A 7C E8 21 : A3 08 10 14 00 1A 7C EA 23 : A3 08 10 14 00 1A 7C EC 25 : A3 08 10 14 00 1A 7C EE 27 : A3 08 10 14 00 1A 7C F0 39 : A3 08 10 14 00 1A 7C F2 3B : A3 08 10 14 00 1A 7C F4 3D : A3 08 10 14 00 1A 7C F6 3F : A3 08 10 14 00 1A 7C F8 31 : A3 08 10 14 00 1A 7C FA 33 : A3 08 10 14 00 1A 7C FC 35 : A3 08 10 14 00 1A 7C FE 37 : A3 08 10 14 00 1A 7D 00 CB : A0 08 10 14 00 1A 7D 02 C9 : A0 08 10 14 00 1A 7D 04 CF : A0 08 10 14 00 1A 7D 06 CD : A0 08 10 14 00 1A 7D 08 C3 : A0 08 10 14 00 1A 7D 0A C1 : A0 08 10 14 00 1A 7D 0C C7 : A0 08 10 14 00 1A 7D 0E C5 : A0 08 10 14 00 1A 7D 10 DB : A0 08 10 14 00 1A 7D 12 D9 : A0 08 10 14 00 1A 7D 14 DF : A0 08 10 14 00 1A 7D 16 DD : A0 08 10 14 00 1A 7D 18 D3 : A0 08 10 14 00 1A 7D 1A D1 : A0 08 10 14 00 1A 7D 1C D7 : A0 08 10 14 00 1A 7D 1E D5 : A0 08 10 14 00 1A 7D 20 EB : A0 08 10 14 00 1A 7D 22 E9 : A0 08 10 14 00 1A 7D 24 EF : A0 08 10 14 00 1A 7D 26 ED : A0 08 10 14 00 1A 7D 28 E3 : A0 08 10 14 00 1A 7D 2A E1 : A0 08 10 14 00 1A 7D 2C E7 : A0 08 10 14 00 1A 7D 2E E5 : A0
Na dann bruach ich ja garnicht weitersuchen.... Dann kann es keine "richtige" CRC-Berechnung sein sondern irgendwelchen Berechnungen. Kann es vielleicht sein dass es doch keine Prüfsumme ist? Bei deinen Beispielen gibt es ja nur 2 Prüfsummen für 20 verschiedene Telegramme. Was macht denn dann eine Prüfsumme für einen Sinn wenn die Prüfsumme keine Sicherheit bietet? Bei anderen Telegrammen habe ich allerdings festgestellt dass sich die "Prüfsumme" schon ändert wenn sich nur ein einziges Bit geändert hat. 08 00 18 00 07 01 11 00 00 00 00 00 60 80 00 02 0D 01 1D 00 00 0C 30 48 00 CB FF 00 00 4B 00 08 00 18 00 07 01 10 00 00 00 00 00 60 80 00 02 0D 01 1D 00 00 0C 30 48 00 CB FF 00 00 94 00 Gruß Ingo
Angehängte Dateien:
-
km271.gif
30 KB
Aus den Fotos habe ich mal den angehängten Schaltplan extrahiert. Die Werte für die Widerstände und Kondensatoren kann ich nicht erkennen. R2, 1003 (100k) konnte ich erkennen. Die Widerstände werden möglicherweise für die Modulerkennung benötigt. Ich habe versucht ohne die R/C-Beschaltung mit 2400,8N1 ein Byte 0x02 (STX) zu schicken, darauf erhalte ich keine Antwort (DEL, 0x10). Wird ein eingestecktes KM271 irgendwo im Display-Menue angezeigt?
@IngoF > Kann es vielleicht sein dass es doch keine Prüfsumme ist? > Bei deinen Beispielen gibt es ja nur 2 Prüfsummen für 20 verschiedene > Telegramme. Was macht denn dann eine Prüfsumme für einen Sinn wenn die > Prüfsumme keine Sicherheit bietet? Nene, der letzte Wert ist die XOR über alle Daten+CRC ;-) Die CRC8 ist eine schwache Prüfsumme, aus diesem Grund ändert sich die auch relativ gleichmaessig mit den Daten. Je nachdem welches Bit sich in welchem Byte ändert, geht es in die CRC anders mit ein. Es ist auf alle Fälle ist die CRC kein einfaches XOR.
> Wird ein eingestecktes KM271 irgendwo im Display-Menue angezeigt?
Im Installationsmenue erscheint unter KESSEL der Menuepunkt
ABGASTEMPERATURSCHWELLE, wenn das KM271 erkannt wurde.
Rudi schrieb: > Nene, der letzte Wert ist die XOR über alle Daten+CRC ;-) Dann habe ich Dich falsch verstanden.. Ich dachte die A3 und A0 wäre die Prüfsumme... deswegen auch meine Verwunderung. 20 verschiedene Telegramme und jedesmal die Prüfsumme "A3". Was ist denn die A3? > Je nachdem welches Bit sich in welchem Byte ändert, geht es in die CRC > anders mit ein. Es ist auf alle Fälle ist die CRC kein einfaches XOR. Hatte es so verstanden dass eine CRC durch eine Polynomdivision errechnet wird. Wenn die anders errechnet wird ist es keine CRC sondern nur eine andere Art der Prüfsumme, oder habe ich das falsch verstanden. Hatte auch mal einige Prüfsummen für Telegramme mit XOR berechnet und habe keine Übereinstimmung gefunden. Habe wohl was falsches berechnet.... Werde das auch mal testen... Gruß Ingo
Angehängte Dateien:
-
km271.gif
27 KB
@Rudi: Richtig, das R/C Netz R1/R2/C5 stimmte nicht. Gegenüber dem Foto ist im Schaltplan der Edgeconnector um 180° gedreht, damit er mit der Aufsicht auf die Steuerung von vorne übereinstimmt. Zur Orientierung noch ein Lageplan des Modul-Steckverbinders auf der Busplatine mit den Pinnummern.
chipshuffler schrieb:
> Wird ein eingestecktes KM271 irgendwo im Display-Menue angezeigt?
Wenn man am Drehknopf dreht erscheint nach der Kesseltemperatur dann
die Abgastemperatur. Man muss also nicht ins Installationsmenue.
Kennt jemand eine günstige Bezugsquelle für einen geeigneten PTC
für die Abgastemperaturbestimmung?
@Joachim K. Es gibt bei B. eine Liste mit den Werten und Bezeichnungen für die unterschiedlichen PTC, hatte ich mal gesucht, aber keinen Link mehr. Die Module werden über die Temperatursensoren identifiziert und nicht über Steuerleitungen ... ;-). Die Leitungen gehen an die Steuerplatine und dann die ADC-Werte über das Flachbandkabel an die Displayeinheit, die diese dann identifiziert. Alles sehr abenteuerlich ... @chipshuffler Schau dir die Sensorleitungen besser nochmal an. Das ist übrigens eine Schutzbeschaltung für die Eingange mit Pullup oder Down. Mach dir deine Heizung nicht kaputt ! Da hängt ein ADC dran. @Ingo F. > Was ist denn die A3? XOR über die Daten und CRC > Wenn die anders errechnet wird ist es keine CRC sondern > nur eine andere Art der Prüfsumme, oder habe ich das > falsch verstanden. Ich denke das ist schon eine CRC. Evtl. etwas abgeändert. Ich habe mich damit nicht wirklich tiefgründiger beschäftigt. Ich sehe aber in den Betriebsstunden einen guten Ansatz um diese zu finden.
Rudi schrieb: > @Joachim K. > > Es gibt bei B. eine Liste mit den Werten und Bezeichnungen für die > unterschiedlichen PTC, hatte ich mal gesucht, aber keinen Link mehr. > > Die Module werden über die Temperatursensoren identifiziert und nicht > über Steuerleitungen ... ;-). Die Leitungen gehen an die Steuerplatine > und dann die ADC-Werte über das Flachbandkabel an die Displayeinheit, > die diese dann identifiziert. Alles sehr abenteuerlich ... An das KM271 kann man einen PTC zum Messen der Abgastemperatur anschließen (FG 1 und 2 in meinem Photo der Platine). Ich suche mal den Wert raus.
Angehängte Dateien:
-
km271.gif
29 KB
@Joachim K.: Nach der Kennlinie müsste die 2107 mit ca. 10k als Ersatz für den Abgfasfühler-PTC erkennen. Ich habe ein Paar Widerstände aus deinem Foto erraten (siehe Schematic) und Testweise an die 2107 angeschlossen (ohne den FG-Fühler). Damit erkennt die 2107 das "Modul" noch nicht. Kannst du nochmal schauen, welche Werte die Widerstände (bzw. womit sie beschriftet sind)auf deiner Platine haben? Ich vermute aber, dass die Kommunikation über das KM271 auch laufen müsste, wenn kein Abgasfühler angeschlossen ist. Der zweite ADC Eingang (festverdrahtet mit Widerstand) auf dem K4 Board-Stecker ist dann wohl für den Solar-Fühler (FM244).
Die Verbindung bei C6/C7/R3 ist nicht klar. Ist C6 mit C7 verbunden und C7 mit R3 ?
Hallo, Zum EMS-Telegrammaufbau habe ich noch eine Kleinigkeit herausgefunden: das Erst Byte ist die Absenderadresse, das zweite Byte die Zieladresse. Wenn das Ziel auf dieses Telegramm antworten soll ist das Bit 7 gesetzt. 10 88 ...ist ein Telegramm von 10 (RC30/RC35) zu 08 (UBA3/MC10) mit der Aufforderung zu antworten. Die UBA3/MC10 antwortet dann mit dem Telegramm 08 10 ... Alle ein Byte Telegramme mit Bit 7 gesetzt ist ein normales Polling. 90 soll dann 10 aufordern zu antworten. Wenn die RC30 oder RC35 angeschlossen ist antwortet diese. Wenn es nichts besonderes gab antwortet dir RC30/35 nur mit der eigenen Adresse 10 Wenn Daten gesendet werden kommt als nächstes ein Byte für den Telegrammtyp gefolgt von den Daten und zum Schluss die Prüfsumme. Das Break ist immer der Abschluss vom Telegramm. Habe inzwischen auch ein eigenes Interface mit einem OP damit ich nicht immer zum Dachboden muss um was zu testen. Jetzt kann ich mich auch parallel zur RC30 dranhängen und mitloggen. Gruß Ingo
Arrrggggghhhhhhhh... Und ich wundere mich wieso der Thread jetzt so riesig geworden ist. RE-ABO... aus irgend einem Grund habe ich keine Mails mehr bekommen. Sorry Leute, aber ohne die Mailbenachrichtigungen habe ich den Thread irgendwie vergessen. Habe eben mal alles neue seit Oktober überflogen und muss sagen: @Rudi: Godlike! wirklich godlike. Mehr fällt mir dazu gerade nicht ein :) Die Frage nach meinem zweiten Heizkreis (nein, habe nur einen an der logamatic aktiv) hat sich ja wohl erübrigt. Ich werde mir den Thread noch vor Weihnachten nochmal im detail anschauen muessen... Freue mich jetzt schon darauf. Ich überlege mir gerade ob ich die ganzen Informationen im Wiki strukturieren soll (mittlerweile unwichtig gewordenen "schrott" natürlich ausfiltern). Besteht da interesse, dann würde ich das schön strukturiert aufbauen und den Link posten? Gruss, Malte PS: hoffentlich bleibt die mailbenachrichtigung jetzt aktiv, hab momentan wieder viel zuviel aktives im Kopf ;)
Hallo Malte, ist eine gute Idee... Vermutlich wird das dann aber nur ein Wiki über die 2107. Oder gibt es da auch einen Bereich für den EMS-Bus (RC30/35)? Gruß Ingo
Ne, schon beide getrennt - ich versuche halt die infos so weit es geht auseinander zu halten :-) Ich habe mich aben mal hingesetzt und versucht, alles bisher verifizierte in das Wiki zu strukturieren. Dabei ist mir aufgefallen, dass in den letzten Wochen der Wunsch nach einer Doku/Projektplattform gekommen ist. An sich kann man sowas schon per SourceForge lösen... Für die Dokumentation würde ich schon ein Wiki vorschlagen. Es kommt nur darauf an wie durchdacht man das ganze strukturiert. Ich könnte so ein Setup machen, so dass wir dann alle darin editieren können (momentan ist es halt in meinem Scratchpad wiki drin). Für Sourcen würde ich vorschlagen das ganze per SVN zu machen. http://wiki.neo-soft.org/index.php/Heizungsschnittstelle http://wiki.neo-soft.org/index.php/Heizungsschnittstelle/Logamatic2107 http://wiki.neo-soft.org/index.php/Heizungsschnittstelle/ServiceKey Also ich biete mich gerne an, das einzurichten und zu hosten. @rudi: sehe ich das richtig dass diese aufsteckplatine sowas wie eine eierlegende Wollmilchsau werden soll? :) Auf jeden Fall vielen Dank für deinen Breakthrough bei der 2107!
@all: Habe ich das jetzt richtig verstanden, dass der neue Erkenntnisstand (Logamatic 2107) wie folgt aussieht: 1) KM271 ist ausser dem FG Anschluss NICHTS anderes als ein TTL->RS232 Umsetzer? 2) Auf dem Sockel K4 liegen Spannungsversorgung (24 und 5V) sowie eine asynchrone serielle Schnittstelle (RX/TX) sowie der I2C Bus (SDA/SCL) auf? 3) Temperaturen werden nicht über I2C übermittelt sondern nur über die RS232 oder eben als gemultiplexter ADC Wert am Flachbandkabel? Ich frage mich nämlich gerade ob Rudis Aufbau nötig ist oder ob es für mich auch einfacher gehen könnte (in Form einer Steckkarte für K4). Muss zu meinem Leid sagen dass ich die Bestückung von miniaturbauteilen nicht hin bekomme ;-) Temperaturen brauche ich schon, werde deshalb wahrscheinlich nicht drum herum kommen, ebenfalls die Bedieneinheit anzuzapfen :-) Gruss, Malte
@Malte Bayer > Ich frage mich nämlich gerade ob Rudis Aufbau nötig ist oder ob es für > mich auch einfacher gehen könnte (in Form einer Steckkarte für K4). Wenn der Schaltplan für das KM271 klar ist, dann reicht es aus. Die Daten kommen dann, nach der beschriebenen Methode, über die RS232. @chipshuffler Bist du schon weiter gekommen ?
@Malte Bayer > Für die Dokumentation würde ich schon ein Wiki vorschlagen. Es kommt nur > darauf an wie durchdacht man das ganze strukturiert. Das sieht doch schon gut aus. Hauptsache das wird für einzelne Nachrichten nicht unübersichtlich. > sehe ich das richtig dass diese aufsteckplatine sowas wie eine > eierlegende Wollmilchsau werden soll? :) Nein ;-) Die Platine ist halt aus der Not und dem bisherigen Stand der Dinge entstanden. Die Wahl der Bauteile liegt an der Platinengröße (Preis) und den vorhandenen Bauteilen. Die Datenerfassung ist auch nur ein kleiner Teil. Dazu kommen noch diverse extra Temperatursensoren an den Wasserleitungen etc.. Ich kann nur jedem die Überprüfung der richtigen Einstellungen der Heizung empfehlen, besonders bei der 2107 gibt es schon einige Überraschungen und Optimierungsbedarf. Je nach Budget für den Einbau und Heizungsbauer können da schöne Geldverbrennanlagen entstehen.
Ja das ist schon mein Ziel dass ich das ding optimiere. Ich habe die Heizung im Februar selbst mit eingebaut (parametrisierung nicht dem heizungsmensch ueberlassen). Komisch finde ich auch dass es nur 3 Gebäudetypen gibt - völliger Quatsch bei meiner Konfiguration, da passt keine der 3 Einstellungen. Das dumme im moment ist, dass ich mir zur zeit auf dauer im Heizraum den hintern abfriere... da hats nur noch 10°C wenns draussen am Gefrierpunkt ist. Das war letztes jahr mit 32° noch anders ;-) Ich versuche mal ob ich mit den bisherigen Infos an K4 weiter komme. den Abgasfühler brauche ich ja hoffentlich nicht. Wegen dem Wiki: Sowie es weitere Infos gibt mache ich daran weiter. Ein Datagram zu dokumentieren ist da auch kein riesen Act, da kann ich ein Template für machen. Gruss & gute nacht, Malte
Angehängte Dateien:
-
km271.gif
68 KB
Nach gut einer Stunde bei 10°C im Keller gibts einige neue Ergebnisse: @Rudi: Ja, die Schaltung war nicht richtig. Die Verbindung R3,C6,C7 stimmte nicht. Inzwischen wird das "Modul" erkannt und ABGAS --- wird im Display angezeigt. Ich habe dazu einen 1k Dummy-Widerstand an FG Pin 1+2 angeschlossen. Ich habe dann zum Anschluss an den PC einen USB-TTL-RS232 Adapter von FTDI http://www.ftdichip.com/Documents/DataSheets/Modules/DS_TTL-232R_CABLES_V201.pdf angeschlossen. Damit umgehe ich den Umweg über RS232 und COM-Port, da das Netbook nur noch USB und keine RS232-COM-Ports hat. Hier die Verdrahtung mit den Farben aus dem FTDI-Datenblatt und den Signalen aus dem angehängten Schaltplan: Orange an UARTTX Gelb an UARTRX Schwarz an 0V Grün/Braun verbunden (RTS/CTS) Beim Einschalten sendet die 2107 mit 2400Baud,8N1 ein STX (02) als Sendeaufforderug aus. Dann folgt ein Protokoll mit der Prozedur 3964R (ein betagtes S5/S7 SPS Kommunikationsprotokoll). Danke an Joachim K. für die Fotos und die Protokollbeschreibung. Angehängt ist mein Trace (der Anfang fehlt, ist aus dem Kopf rekonstruiert). Folgende Erkenntnisse gibt es: Ein Protokollfehler wird mit NAK beantwortet (das letzte Byte ist immer die Prüfsumme als XOR vom ersten bis zum letzten Byte). 04 00 07 01 81 A5 00 E3 10 03 D6 Es gibt kein Längenbyte in der Nachricht. Der Parser sucht nach 10 03 (DLE, ETX), nach folgt die Prüfsumme. Ein DLE (10) in den Daten wird beim Übertragen verdoppelt und geht in die Prüfsummenberechnung ein (muss beim Empfangen wieder entfernt werden). Der LogMode wird mit EE 00 00 10 03 FD eingeleitet. Danach kann mit 10 (DLE) jeweils der nächste Datensatz angefordert werden. Zuerst folgt der Inhalt des EEPROMs Page 0 und 1. Das EEPROM ist in Records mit 6 Bytes+Prüfsumme eingeteilt. Die EEPROM Prüfsumme wird nicht übertragen, dafür wird ja eine Nachrichtenprüfsumme über die Nachricht neu berechnet angehängt. Die Page 0 enthält die Modus-Parameter, die Page 1 die Absenk/Heizzeiten. Die mit Adresse 0xxx beginnenden Datensätze (EEPROM-Konfiguration) haben eine Länge von 10 Bytes+Prüfsumme. Die EEPROM-Records an Adresse 0000 und 0038, sowie Adresse 0007 und 003F sind (wahrscheinlich zur Verifikation) identisch und enthalten die Heizkreis 1 und Warmwasser-Betriebsart/Soll-Temperaturen. Ein 65 ("e" für empty) in den EEPROM-Daten kennzeichnet beim Lesen und Schreiben zu ignorierende Bytes. Nach Einigen Sekunden ohne Aktivität sendet die 2107 ein STX (02) als Sendeaufforderung. Nach den EEPROM-Konfigurationsdaten folgen die Ereignisse die an einer 16-Bit Adresse mit gesetztem Bit 15 (8xxx) erkennbar sind. Diese Datensätze haben eine Länge von 5 Bytes + Prüfsumme und folgen der Beschreibung von Joachim K. Die nächste Frage ist nun, ob die Schreibzugriffe im Direktmodus mit dem Führenden Byte 0xB0 (Parameter Setzen) oder 0xDD (Direktmodus) stattfinden und welche Adressen für die Schreibzugriffe verwendet werden können.
Mit 0xDC kommst du wieder in den Normalmodus und mit 0xDD Direktmodus. Nach 60sec. ,ohne Nachrichten, schaltet die Anlage automatisch in den Normalmodus. Der Wert z.B. 0x80 XX ist die Adresse (Heizkreis 1) und ein Offset. Es wundert mich das bei Joachim K. der Offset bei anderen Adressen nicht bei 0 anfängt. Evtl. ein Schreibfehler !? Mit B0 sollten die Parameter verändert werden können. Es kann aber sein das die Adressen anders sind. Versuch mal den Befehl 0xA1 <ADRESSE> zum lesen der Schaltuhrparameter. Oder mit 0xA2 um die Monitordaten von <ADRESSE> zu holen. Immer im Direktmodus. Sehen die Nachrichten im Normalmodus anders aus ?
Thx Chipshuffler. Wiki geupdated. Habe eben einen KM271 Nachbau als kleine Steckkarte geroutet. Muss nochmal gegenchecken ob ich mich nicht mit den Anschlüssen vertan habe, mache so selten doppelseitige Platinen ;) Werde das ganze dann am Wochenende mal aufbauen und testen, mal sehen, wenn alles klappt bin ich ab nächster woche dabei mit Protokolltests. Gruss, Malte
Dann denk auch gleich an Serienwiderstände in den Datenleitungen. Die Anlage rotzt ganz schon rum. Ein geschirmtes Kabel, z.B. altes USB-Kabel ist auch von Vorteil.
@Rudi: Hatte vor den XPORT den ich hier eh noch rumliegen habe direkt auf das Steckmodul drauf zu pflastern. Dann erspare ich mir auch gleich Frostbeulen durch zu langen Aufenthalt @ 10°C und kann bequem vom Sofa aus kommunizieren ;) Gleichzeitig habe ich noch alle Anschlüsse (ausser die 4 für FG) auf einer Pinleiste ausgeführt, falls man alternativ dann doch noch nen externen RS232 Wandler einbauen möchte. Die Bestückungsseite zeigt nach hinten wenn man vor der Steuerung steht. Das heisst man hat da noch massig platz, ein Sandwitch drauf zu packen (auf der anderen Seite ist ja K3 und K1 im Weg :) Was für ne Spannung hat die Zener überhaupt? Braucht es die überhaupt? Soweit mein Verständnis da geht, begrenzt diese doch die Spannung die ich extern an FG anlegen könnte. Da da aber entweder nichts oder ein Widerstand dran hängt ist die doch an sich sinnlos oder? Selbst ein 0 Ohm Widerstand sollte da nicht weh tun, oder habe ich mich da verguckt? @all: ich verifiziere das Layout noch, wenn alles passt schmeisse ich die Boarddaten und natürlich jegliche neuen Erkenntnisse ins Wiki.
Ist Pin 3/4 eine Versorgungsleitung ? Sollten es nicht auch 100k an 4/8 und 3/7 und dann 1k an 8/7 auch tun ? Die Diode soll wohl eher den Eingang schützen. Wenn da ein paar Meter Kabel dran kleben, fängst du dir alles ein was da so in der Luft liegt. Die Kondensatoren sind wohl eher zum Glätten der Signale gedacht, evtl. ein RC-Filter gegen Netzbrummen (R1/C7) (Versorgungsspannung???, kann da mal jemand messen???) und bei R2/C5 das gleiche für den Eingang. Die Anzeige --- als Wert, bedeutet ein Wert ausserhalb der Spec.. Beim XPORT würde ich das Gehäuseground vom Netzwerk "erstmal" nicht mit dem Ground der Anlage verbinden (wenn es nicht schon intern mit Ground verbunden ist).
Hallo, ich habe in Verbindung mit einem Buderus Service Key versucht meine Heizung (GB-125) abzufragen. Leider konnte ich an den Pins 2,3 der RS232 des Keys keine keinerlei Daten sehen können (via Oszi). Muss der Key via Steuerzeichen aktiviert werden oder was könnte ich sonst noch falsch machen ? Wer kann mir hierzu helfen ?
Die mitgelogten Telegramme hier haben nichts mit dem Service-Key (Hardware) von Buderus zu tun. Im Servicekey ist irgendwelche Hardware drin die die Kommunikation mit der Heizung übernimmt. Hier geht es ja um die Schnittstelle an der der Service-Key angeschlossen wird. Soweit ich weiß sendet die Buderusoriginal-Software an den Servicekey ein STX (0x2). oder ein aderes Steuerzeichen damit der Servicekey antwortet. Habe keine Ahnung wie die Kommunikation mit dem Service-Key genau läuft. Gruß Ingo
> Ist Pin 3/4 eine Versorgungsleitung ? Vermutung: 3 = AGND, 7,4,8 sind ADC-Inputs für Vorlauf HK2, Abgas und Solar. Als ich einen der Eingänge mal mit 5V bauaufschlagt habe, zeigte die 2107 danach VORLAUF --- und einen Heizkreis 02 im Display und meinte zeigte FEH FM241 (das Mischer-Modul) wäre nicht gefunden worden. Ich habe den Heizkreis 02 dann per Menue entfernt und die Fehlermeldung verschwand. Die Kondensatoren sind als Tiefpass-Filter drin. Die grossen Vorwiderstände 100k legen wohl nur die unbenutzten ADC-Eingänge (Vorlauf, Solar) auf definierte Pegel, vermutlich wird dadurch aus das KM271 vom FM244 Solarmodul im gleichen Steckplatz unterschieden. > Sollten es nicht auch 100k an 4/8 und 3/7 und dann 1k an 8/7 auch tun ? Für einen Nachbau als Dummy reicht das. Die Werte im Schaltplan sind aus dem Foto "erraten". @Joachim K. kannst du nochmal prüfen, wie die Beschriftung der 0805 Widerstände ist? Die Kondensatoren sollten unkritisch sein (10nf-1uF). Weglassen wie bei meinem Testaufbau geht auch). Ich habe ja keine Fühler angeschlossen. @Rudi: Es sieht so aus als wäre bei den Status-Nachrichten wirklich 80 für HK1 und 81 für HK2, 84 für Warmwasser, 88 für Brenner/Kessel und 89 für sonstiges Verwendet und das nächste Byte zählt einfach von 00..xx durch. Der Versuch mit dem Direkt-Modus steht noch aus, die 3964R Prozedur lernt gerade den Schreibzugriff...
> @Rudi: Es sieht so aus als wäre bei den Status-Nachrichten wirklich 80 > für HK1 und 81 für HK2, 84 für Warmwasser, 88 für Brenner/Kessel und 89 > für sonstiges Verwendet und das nächste Byte zählt einfach von 00..xx > durch. Die 89 ist die Konfiguration.
anyway http://www.2shared.com/file/10061368/f06b81c3/0001.html http://www.2shared.com/file/10061446/20aad8c3/0002.html
Inzwischen konnte ich auch Schreibzugriffe auf die 2107 zu machen. D.h. Ein- Ausschalten (Automatik, Tag, Nacht Manuell) sind getestet und funktionieren über die KM271 Schnittstelle. Die Telegramme entsprechen der Doku für die 4311/12, bis auf die ersten beiden Bytes (B0 und ECO-CAN Adresse). D.h. das Telegramm zum Verändern der Betriebsart/Solltemperaturen: (02) 07 00 65 65 NN TT MM 65 (10) (03) (CC) 07 = TYP Heizkreis 1 00 = OFFSET 0 für Heizkreisparameter 65 = Dont Care NN = Nach-Solltemperatur in 0.5C TT = Tag Solltemperatur in 0.5C MM = Betriebsart (00=Manuell Nacht, 01=Manuell Tag, 02=Automatik) CC = XOR-Prüfsumme In Klammern das 3964R Framing. Eine Umschaltung DD/DC Direktmodus/Normalmodus scheint nicht erforderlich zu sein. Zum Senden wird vorher 0x02 geschickt, die 2107 Antwortet mit 0x10. Dann folgt das Telegramm (s.o) mit DLE(0x10), ETX(0x03) und Prüfsumme am Ende. Bei fehlerfreiem Empfang antwortet die 2107 wieder mit DLE(0x10). Warmwasser Parameter ändern: (02) 0C 07 65 65 65 WW 65 65 10 03 CC 0C = TYP Warmwasser 07 = OFFSET 7 für Warmwasserparameter 65 = Dont care WW = Warmwasser Solltemperatur in 1.0C CC = XOR Prüfsumme Betriebsart Warmwasser ändern: (02) 0C 0E MM 65 65 65 65 65 10 03 CC MM = Betriebsart (00=Manuell Nacht, 01=Manuell Tag, 02=Automatik) Danach sendet die 2107 alle durch den Schreibzugriff veränderten Ereignisse. Ich sehe am Ende übrigens noch Ereignisse vom Typ 0x91 die in keiner 4311/12 Doku beschrieben sind: TYP 91 ADDR=0x9142 0 TYP 91 ADDR=0x9143 32 TYP 91 ADDR=0x9144 110 TYP 91 ADDR=0x9145 0 TYP 91 ADDR=0x9146 255 TYP 91 ADDR=0x9147 0 TYP 91 ADDR=0x9148 0 TYP 91 ADDR=0x9149 0 TYP 91 ADDR=0x914a 0 TYP 91 ADDR=0x914b 0 TYP 91 ADDR=0x914c 0 TYP 91 ADDR=0x914d 0
Na das ist doch mal etwas. Evtl. ist die 91 auch ein Status der Displayeinheit ...
Hat eigentlich irgendjemand einen Service-Key oder RS232-Gateway von Buderus den ich mir mal für ein paar Tage ausleihen könnte? Finanziell würde man sich bestimmt auch einig. Wäre ganz interessant um die Prüsumme herauszubekommen. Gruß Ingo
@ Ingo F.
> Wäre ganz interessant um die Prüsumme herauszubekommen.
Wie das ? Über den Betriebsstundenzähler hast du doch alle Bits die sich
ändern ?!
Hallo Rudi, man könnte z.B. den Betriebsstundenzähler jede Minute Abfragen. Bei mir wird häufig nur jede zweite Minute der Betriebstundenzähler angefragt. Manchmal ist sogar eine Pause von 15 Minuten. Man hätte mehrere Werte und könnte sich die Zählerstände so sortieren dass vielleicht nur ein Bit geändert wird und kann sehen wie sich das auf die Prüfsumme auswirkt. Vielleicht könnte man sich ein Telegramm über das man mit der PC-Software Daten sendet nehmen und beliebig verändern und sehen wie sich das auf die gesendete Prüfsumme auswirkt. Wenn sich der Service-Key ähnlich wie das RS232-Gateway oder Fernwirkmodem verhält brauch man beim Senden über den Service-Key keine Prüfsumme. Oder es ist vielleicht nur ein simples XOR wenn es doch eine Prüfsumme gibt. Sieht auch fast so aus als ob vielleicht jemand mit einem Notebook mit orignal-Software (oder vergleichbar) mal vorbeischaut. Der Service-Key, RS232-Gateway, Fernwirkmodem, ... ist wohl das Problem. Kann natürlich sein dass das alles auch nicht weiterhilft... Und natürlich gaaanz viel Neugier auf den Service-Key. Gruß Ingo
Hi Leute, habe eben ersten Test gefahren: Modul nicht erkannt, keine weitere Temperatur (FG) im Display nach Neustart der Steuerung. Muss man da irgendwas einstellen oder sollte die Logamatic das Modul selbst erkennen? Sind die Werte der Widerstände und Kondensatoren ok? (siehe wiki) Ich habe jetzt auch nochmal uebers Platinenlayout geschaut ob ich pins verwechselt habe, kann aber nichts finden. Kann das vielleicht mal jemand verifizieren? http://wiki.neo-soft.org/index.php/Heizungsschnittstelle/Logamatic2107/K4#PCB_Tests http://wiki.neo-soft.org/index.php/Bild:KM271_Nachbau1.gif http://wiki.neo-soft.org/index.php/Bild:KM271_Nachbau2.gif http://wiki.neo-soft.org/index.php/Bild:Km271_schematic.gif Gruss, Malte
Ah sorry, hatte ich uebersehen. Auch mit 1k geht nix. Also ich habe als Anzeige nur Kessel, WW, Aussen und Betriebsstunden. Wenn ich im HK1 die (nicht vorhandene) Fernbedienung aktiviere habe ich noch ne weitere Temperatur "Raum1" die mit --- angegeben ist (normal, is ja kein Signal da). Das wars dann auch schon. Falls ich nicht irgend einen Leichtsinnsfehler im Layout habe (den ich nicht finden kann) verstehe ich nicht wieso das Teil nicht als Modul erkannt wird. @Chipshuffler: Stimmt der Schaltplan mit deinem Selbstbau überein? Welche Werte hast du für R1 R2 und C5 verwendet? Hast du D1 weg gelassen oder wenn ja mit welchem Wert bestückt? Gruss, Malte
Hallo, die KM271-Nachbauplatinen sehen ja schon ganz gut aus. Vielleicht kannst Du ja noch die beiden Abgriffe für RX/TX vom XPORT oder MAX232 neben die richtigen UART-Pinne setzten. Dann könnte man die richtige Schnittstelle jumpern und muss keine Kabel umstecken Gruß Ingo
@hellraiser: Es sieht so aus, als wäre das Layout genau seitenverkehrt (Bottom/Top-Layer Pins vertauscht), d.h. Pin 1 und 2 vertauscht, Pin 3 und 4 vertauscht etc. Dadurch sind auch 0V und 5V vertauscht und der SP232 dürfte gelitten haben. Ich habe alle Kondensatoren und D1 weggelassen. Die Werte für R1 und R2 sind wie im Schaltplan bestückt. Ich habe dein PCB um 180° gedreht und mit dem Foto von himtronics verglichen. Nach Vergleich mit dem Schaltplan bin ich der Meinung, dass das Pinning im Schematic stimmt. Die Position der Pinnummern in dem Kasten unten bezieht sich auf die Position der Buchse auf der Busplatine.
@IngoF: Ja, ist jetzt drin. Ich bin mir nur noch nicht sicher ob ich RX/TX vertauscht habe. Wird sich in der nächsten Woche zeigen :) @chipshuffler: Viel schlimmer. ich muss irgendwie beim layouten einen totalaussetzer gehabt haben. Ich schiebe es mal auf die vielen Telefonate mit den Kunden zwischendrin ;-) Spannungsversorgung war richtig rum. Die Pins für das Widerstandsgebrösel auch, nur habe ich mit der Verschaltung total gepennt (böser fehler drin, aber die logamatic lebt noch :) @all: Habe jetzt die rev C für das Selbstbaumodul soweit fertig, dass es korrekt erkannt wird. Ich versuche noch die Widerstände auf einen PT1000 abzustimmen, so dass die Abgastemperatur nachher auch halbwegs korrekt ist und nicht irgend einen Mist anzeigt der eh nicht stimmt. http://wiki.neo-soft.org/index.php/Heizungsschnittstelle/Logamatic2107/K4#KM271_Selbstbau-Modul Alles was ich bisher habe ist im wiki aktualisiert. Aber bitte sparsam mit Kommentaren zu den Bildern, ich habs echt schwer mit diesem scheiss doppelseitigen Basismaterial mit weisser Schutzfolie. Ich hätte die dinger einfach in die tonne kloppen und mir noch nen stapel Bungard Material holen sollen :-P Ansonsten werde ich jetzt die Arbeit mal ruhen lassen. In diesem Sinn wünsche ich euch allen schöne Feiertage! Gruss, Malte
Soweit ich das bisher beurteilen kann funktioniert das Einsteckmodul. bekomme Antwort von der Steuerung (Logmode aktiv, dann die events pollen). Mir ist da allerdings etwas aufgefallen: Heizkreis 2 habe ich im Setup auf "Kein" eingestellt, also abgeschaltet. Abgastemperatur mit 1K Widerstand bei 208°C. Soweit okay vorerst. Das komische ist aber dass sobald das Modul drin steckt die Kesseltemperatur manchmal springt. So passiert es, dass die temperatur normal im 1° Schritt unter irgendwas um 55° sinkt und dann der Brenner gestartet wird. kurz danach springt die temperaturanzeige für den kessel aber auf 67°C (für ein paar sekunden, dann zurück auf 54°C. Dieses Springen stoppt den brenner (halbwegs logisch). Dumm nur dass das immer wieder passiert und der brenner dann für 2-3 sec zündet, dann aber wieder abgeschaltet wird. Ich habs noch nicht raus was das sein könnte, kann das jemand bestätigen oder ist es nur bei mir so? Mir ist aufgefallen dass ich das springen manchmal erzwingen kann indem ich am modul "wackle". Schlachten Kontakt kann ich mir aber schlecht vorstellen, habe extra vorher die Kupferkontakte die in den Sockel gehen blank gereinigt. (vergolden kann ich leider nicht ;) Werde nächste woche nochmal weiter probieren. In dem Zustand lasse ich das Modul erstmal nicht eingebaut. Gruss, Malte
Bei mir springt die Kesseltemperatur nicht, wenn das Modul eingesteckt ist. Ich vermute, dass ein Offset am AGND-Pin am Modulstecker die Messung der Kesseltemperatur beeinflusst.
Okay, das muss ich nochmal genauer angucken. Mir ist eben aufgefallen (ja ich kanns nicht lassen) dass es nicht nur die kesseltemperatur ist. Alle Temperaturen stimmen mit aktivem Modul nicht, Alle Temperaturen werden niedriger ausgegeben als tatsächlich gemessen kurz bevor das modul eingesteckt wurde (Kessel, Speicher, Aussentemperatur). Habe jetzt auch mal nen 500 Ohm Widerstand als Abgassensor verwendet -> 218°C, also sollen 500 Ohm 10° Unterschied ausmachen? da stimmt echt was nicht bei mir. Ich versuche es erst nochmal mit nem steckbrett. Vielleicht habe ich ja auch Leiterbahnen auf der Platine ungünstig gelegt, rudi meinte ja "das ding rotzt rum"... Für Analogmessungen nicht gerade von Vorteil. Gruss, Malte
Moin, trenne doch einzelne Leitungen (Paare) und schau an welcher es liegt !? Gibt es sonst noch Neuigkeiten ???
Angehängte Dateien:
-
EMSlog.png
23 KB
Hallo, da Rudi nachfragt... Ich habe schon mal eine erste Testversion von meinem Java-Programm. Dazu muss Java 1.6 installiert sein. Das ZIP-File entpacken. MySQL muss installiert werden und der Ordner EMSlog aus dem ZIP in das Daten-Verzeichnis von MySQL kopiert werden und gestartet werden. Oder in der MySQL die SQL_Create.sql ausgeführt werden. Das SQL-Script erzeugt die Datenbank EMSlog und die Tabellen für die Telegramme 080018, 080019, 080034 und 10003e an. Das Java-Programm ausführen. Den COM-Port auswählen an dem der Wandler hängt und auf [Verbinden] klicken. Die Daten für MySQL angeben (IP-Adresse, User, Passwort) und auch auf [Verbinden] drückenDas eingetragene Defaultpassword ist password. Die Daten werden von dem Wandler der an der Schaltung hängt empfangen, angezeigt und in der MySQL geloggt. Gleichzeitig werden die Daten aus der MySQL-Datenbank ausgelesen und in der Grafik angezeigt. Bevor man das Programm schließt natürlich auf [Trennen] drücken. Im Moment müssen beide Verbindungen aufgebaut werden. Später sollen man mit dem Programm auch nur loggen oder nur die Daten auswerten können. Je nachdem was man will. Natürlich benötigt man noch den "Wandler" mit ATMega8 und den Komparator der programmiert sein muss. Leider kann ich mein HEX-File nicht wiederfinden. Notfalls eben den von Rudi geposteten C-Quelttext kompilieren und programmieren. Gruß Ingo
Hallo, ich suche ein Interface für meine Heizung um die Daten in meiner Hausautomation zu visualsieren und bin über den Thread hier gestolpert - echt interessant ! Hat jemand eine Leerplatine oder einen Bausatz über ? Gruß Andreas
Hat sich schon jemand mit der Sendeschaltung fuer die RC30 auseinder gesetzt ?
Hallo Rudi habe mal einen kleinen Versuch gestartet. Irgendwo war hier ein link zu einem anderen Thread. Dort war eine Version mit einer ZenerDiode die mit Transistor auf den Bus geschaltet wurde um die Spannung herunter zu ziehen. Habe mal gemessen dass dort dann 160mA fliesen. An der Z-Diode fallen also 1,5 Watt ab. Hatte anders als dort angegeben eine 8,2-Z-Diode genommen statt der 7,5Z-Diode. Allerdings ist dann die Spannung noch höher als 10 Volt. Hatte nur gerechnet ohne mir die Kennlinie der Z-Diode anzusehen. Also war die Lösung mit 7,5-Volt Z-Diode und zwei normalen Dioden (Brückengelichrichter damit die Polung des Busses egal ist) plus Transisitor. Nach dem Senden ist allerdings erst mal längere Stille auf dem Bus. Was auch schon mal öfter bei langen Telegrammen der RC30 vorkommt. Habe mal das mit Deiner Schaltung getestet und noch einen freien Treiber vom MX232 genommen um den Transistor anzusteuern. Habe dazu die Sendeleitung vom PC die ja noch nicht benutzt wurde einfach auf den MAX232 geklemmt. Allerdings müsste ich meiner Software erst noch angewöhnen auf das Polling zu reagieren und das richtige Senden zu können. Gruß Ingo
> Nach dem Senden ist allerdings erst mal längere Stille auf dem Bus. Was > auch schon mal öfter bei langen Telegrammen der RC30 vorkommt. Das könnte auch am fehlenden "Frameerror" liegen, da alle Teilnehmer auf das Ende warten und dann wohl in den Timeout rennen.
Ach ja....... Wenn man aber noch einen Master nimmt bräuchte man den ja nur mit normalen Port-Pins verbinden. Der Slave könnte sich bemerkbar machen wenn ein Polling mit einer bestimmten Adresse kommt und der Master könnte dann einfach sein Telegramm abschicken. Dazu müsste man nicht unbedingt einen zweiten UART nehmen. Ein einfacher Port-Pin mit entsprechender Assembler-Programmierung könnte reichen. Oder gibt es einee Art Software-Uart denn man mit C verwenden könnte? Ideal wäre ja noch ein kleiner Buffer im Master der die Daten decodiert und zwischenspeichert und dann direkt über Ethernet in die SQL-Datenbank schreibt. Habe mir inzwischen ein gebrauchten Laptop gekauft. Der könnte dann automatisch zu einer bestimmten zeit hochfahren, MySQL starten und nach einer bestimmten Zeit wieder herunterfahren. Dann könnte mann den Jahresverbrauch noch stärker drosseln. Sind zwar nur 20Watt, aber selbst das sind schon immerhin 170kW/h. Mein normaler Mini-Tower braucht immerhin 100W. Der Laptop hat natürlich noch den Vorteil der Akkupufferung. Gruß Ingo
>Das könnte auch am fehlenden "Frameerror" liegen,
Wäre möglich.. allerdings habe ich ein Zeichen und ein Break gesendet.
Dieses Break vom Terminal-Programm ist um einiges länger als das
EMS-Bus-Break. Man müsste also noch sehen ob man am PC diese Break-Länge
ändern kann. Aber wenn man einen Master einbaut könnte der automatisch
die richtige Länge erzeugen.
Gruß
Ingo
@Ingo F. könntest du einen kleinen Schaltplan für den TX-Pfad posten ?
Hallo Rudi, kann ich gerne machen. Allerdings nicht mehr heute. Irgendwann im laufe der Woche. Gruß Ingo
Hallo, Habe eine 2107 mit km271. Ich hatte vor laengerer Zeit schon mal mit dem 3964R etwas experimentiert und ein paar Mittschnitte gemacht von der Windows Software (die leider durch crash abhanden gekommen ist). Leider bin ich aus Zeitgruenden nie dazu gekommen es weiter zu analysieren bzw zu implementieren. Hatte aber mit http://libnodave.sourceforge.net/ ein wenig gespielt bis mir die Software zum Vergleich fehlte. Hat hier schon jemand versucht das hier gelernte ueber die Libnodave laufen zu lassen? Ich hatte damals eine NSLU2 dafuer genommen, mit Debian und externer Platte, und USB serial. Ich denke das ist eine Gute Loesung zusammen mit der KM271 oder der ersatzplatine. Mich interessiert jetzt brennend ob jemand etwas auf linux lauffaehiges hat das z.b. auf einer NSLU2 laueft. Gruesse und Hut ab. Sean
Moin, > Hat hier schon jemand versucht das hier gelernte ueber die Libnodave > laufen zu lassen? Ich nicht. Das einzige was mir auf der Seite bekannt vor kam war der "Basic data exchange". Evtl. kannst du ja mal kurz erklären wofür diese Lib. gut sein soll. > Mich interessiert jetzt brennend ob jemand etwas auf linux lauffaehiges > hat das z.b. auf einer NSLU2 laueft. Ja, auf Linux schon, aber bei den Datenmengen ist das schon Tierquälerei ;-). Ist aber auch nur eine Vermutzung, keiner weiss was du vor hast.
Hi, Ich will mindestens den Zustand an/aus nacht/tag/auto erkennen und beinflussen koennen. Soweit moeglich wuerde ich dann gerne Aktuelle Werte Anzeigen lassen koennen (Aussentemperatur, vor/ruecklauf Differenz, etc). Danach ggf. Historische Daten und danach zb. die Zeiteinstellung korrigieren (winter Sommer etc und ggf. mit ntp angleichen). Danach wuerde das Modifizieren der programierten Schaltzeiten selber in betracht kommen. jedenfalls alles Schritt fuer Schritt und moeglichst einfach und wartbar. Fuer mich bedeutet das eine definierte Schnittstelle wie Z.b. das KM271 oder das Ersatzboard und dann Schnittstellen Treiber auf einem System das moeglichst direkt auch als Web interface dienen kann um das ganze autark laufen lassen zu koennen. Der NSLU2 ist da fuer mich interessant da Linux drauf laueft und es ggf. sogar direkt als Entwicklungsumgebung herhalten kann. Ein anderes Beispiel waehre zb. ein Plug computer. Gruesse Sean
Du könntest die Daten in einer mysql Datenbank speichern oder z.B. die rrdtools benutzen. Beides hat seine Vor- und Nachteile.
Hi, Darf ich kurz eine Frage an die Besitzer einer 2107 Regelung einwerfen ? Man kann ja die Versionsnummer abfragen, falls jemand hier eine Version größer 3.14 hat, bitte mal kurz melden. Vielen Dank !
Angehängte Dateien:
-
EMSlog.gif
17 KB
Rudi schrieb:
> könntest du einen kleinen Schaltplan für den TX-Pfad posten ?
hier mal der erste Versuch des Schaltplans meiner laufenden Platine. Der
Gleichrichter sorgt dafür das man den Bus beliebig anklemmen kann.
Ist natürlich noch nicht die entgültige Version.
Gruß
Ingo
In den TX-Pfad sollte ich noch den zweiten Comperator einbauen damit der Transistor nicht direkt über die serielle Schnittstelle angesteuert wird, oder? Die Spannungswandler des MAX232 wird noch für die Versorgung der Comperatoren benutzt. Hatte leider keinen anderen Comperator/OP greifbar der ohne +-10V auskam. Kritik und Anregungen sind gerne willkommen. Gruß Ingo
> hier mal der erste Versuch des Schaltplans meiner laufenden Platine. Der > Gleichrichter sorgt dafür das man den Bus beliebig anklemmen kann. Danke ! Auf welche Spannung ziehst du das Signal runter und welcher Strom fließt dann ?
Hallo! Ich würde gerne mein Logamatic 2107 an die Haussteuerung (fhem) anschließen, aber leider bin ich kein Hardware- sondern ein Software- Bastler. Ich habe mich auch damit abgefunden, den KM271 zu kaufen, leider weiss ich nicht wo. Ich habe auch keine Angst von irgendwelchen nachbauten, und ob es via RS232 oder Ethernet, ist mir auch egal, aber soweit ich es sehe kann man keine fertigen Alternativen kaufen. Kann mir hier jemand weiterhelfen? Gruss, Rudi (der Zweite :)
@Rudolf Koenig > Ich habe mich auch damit abgefunden, den KM271 zu kaufen, > leider weiss ich nicht wo. Frag einfach deinen Heizungsmenschen, wenn er mal wieder zur Wartung da ist, der besorgt dir das Modul. Die KM271-Alternative ist irgendwie eingeschlafen !?!?!?!?
Ziehe im Moment auf 10Volt herunter. Ist ja vergleichbar mit der RC30. Ein Test mit normalen Wiederständen hat gezeigt dass dann 160 mA fließen wenn man die Spannung so weit herunterzieht. Deswegen auch die 1,3 Watt Z-Diode. Habe allerdings im Moment eine 8,5 Volt Z-Diode drin und nur eine Diode. Das dürfte dann ja der 7,5Volt Diode mit vorgeschalteten Gleichrichter entsprechen. Wäre vielleicht auch eine Idee den MAX232 wegzulassen und den X-Port dafür zu nehmen. Dann müsste ich aber noch einen OP/Comperator nehmen der mit 5 Volt auskommt. Hätte den Vorteil dass man überall aus dem Netzwerk drauf zugreifen könnte.. SOgar aus der Ferne wenn man will. Gruß Ingo
Hi, ich suche eine KM271 Platine. Hat jemand eine über oder läßt jemand demnächst welche machen ? Gruß Andreas
> Ziehe im Moment auf 10Volt herunter. Ist ja vergleichbar mit der RC30. > Ein Test mit normalen Wiederständen hat gezeigt dass dann 160 mA fließen > wenn man die Spannung so weit herunterzieht. Deswegen auch die 1,3 Watt > Z-Diode. Bist du sicher das 160mA okay sind ? Hört sich für mich, aus dem Bauch heraus, etwas viel an. Wenn man von Störungen ausgeht dann ist das sicherlich berechtigt. > Wäre vielleicht auch eine Idee den MAX232 wegzulassen und den X-Port > dafür zu nehmen. Dann müsste ich aber noch einen OP/Comperator nehmen > der mit 5 Volt auskommt. 3-5V wären ausreichend, dann kann man direkt einen uC seiner Wahl anschalten. Ich frage wegen der Schaltung mal einen anderen Hardwerker ( ich bin keiner ;-) ). > Hätte den Vorteil dass man überall aus dem Netzwerk drauf zugreifen > könnte.. SOgar aus der Ferne wenn man will. Jup.
@Andreas > ich suche eine KM271 Platine. Hat jemand eine über oder läßt jemand > demnächst welche machen ? Es gibt hier keine Plagiate. Alles hausbacken ;-)
@ rudi:
>Die KM271-Alternative ist irgendwie eingeschlafen !?!?!?!?
Naja. eingeschlafen noch nicht.
ich bin noch etwas gefrustet wegen dem offensichtlich bescheuerten
layout. Ich muss das nochmal neu machen, scheinbar hätte ich nicht die
gesamte fläche als gnd nehmen sollen bzw so wie es aussieht gibts da
einen getrennten agnd.
Jedenfalls ist das layout so nicht brauchbar (verfaelscht alle
gemessenen temperaturen im system um mehr als 10°C
Werde mich nochmal dran setzten sobald ich wieder mehr zeit habe!
Gruss, Malte
@Rudi Rudi schrieb: >> ich suche eine KM271 Platine. Hat jemand eine über oder läßt jemand > >> demnächst welche machen ? > > > > Es gibt hier keine Plagiate. Alles hausbacken ;-) okay, ich nehme auch eine hausgebackene ;-) Vielleicht erbarmt sich ein Bäcker.
Ich habe eine erste Version eines fhem Moduls fuer KM271 implementiert, vielen Dank nochmal an alle die das Protokoll dokumentiert haben. Die in dieser Liste erwaehnten Buderus Dokumente haben auch etwas geholfen, zusaetzlich gibt es noch den hier nicht erwaehnten 63011377.pdf Ich habe die Daten eine Weile protokolliert, siehe die Plots in dem Abschnitt http://www.koeniglich.de/fhem/commandref.html#KM271 Kann jemand mir erklaeren, was der Logamatic mit "Kesselintegral" meint? Laut Buderus Doku wird es in KK gemessen (was auch immer das wiederum ist). Weiterhin meldet mein KM271 nachdem ich es ins logmode setze nur noch die Aenderungen, aber keine Konfigurationsdaten bzw. Zeitprogramm, wie es in der Doku von himtronics steht. Btw. der wiki scheint seit ein paar Tagen ein Problem zu haben. Gruss, Rudi
@Rudolf Koenig Ich seh da grad deine Vorlauftemperatur & Warmwasser. Kann es sein das die Pumpe deiner Heizung dein WW in den Vorlauf der Heizung drückt ? Ein Freund von mir hat das gleiche Problem. Es ist schön zu sehen wie lange die Temperatur hält wenn sich die Heizung in der Absenkung befindet. > Weiterhin meldet mein KM271 nachdem ich es ins logmode setze nur noch > die Aenderungen, aber keine Konfigurationsdaten bzw. Zeitprogramm, wie > es in der Doku von himtronics steht. Die RC3X sendet auch nur Datensätze die sich geändert haben.
@Ingo F. > In den TX-Pfad sollte ich noch den zweiten Comperator einbauen damit der > Transistor nicht direkt über die serielle Schnittstelle angesteuert > wird, oder? Eine Stromsenke mit OP & FET wäre wohl besser (ich habe da mal einen anderen Hardwerker gefragt). Problem könnte evtl. der RX-Pfad sein, da es keine getrennten RX/TX-Leitungen gibt. Leider bin ich da nicht so bewandert...
Rudi schrieb: > Eine Stromsenke mit OP & FET wäre wohl besser (ich habe da mal einen > anderen Hardwerker gefragt). Ich habe ja keinen festen Strom. Also kann ich keine Konstantstromsenke nehmen. Die Schaltungen die ich bis jetzt gefunden habe waren alles Konstantstromsenken. Ich muss mal nach einer Stromsenke suchen die von der Ausgangspannung abhängig ist.... Rudi schrieb: > Problem könnte evtl. der RX-Pfad sein, da > es keine getrennten RX/TX-Leitungen gibt. Die Sende- und Empfangsdaten sind doch nur auf einer Leitung. Man könnte höchstens die Schaltung so modifizieren dass der Empfangsteil abgeschaltet wird wenn die Daten gesendet werden. Aber denke das kann man doch auch in der Software des ATMega8 machen.. Rudi schrieb: > Leider bin ich da nicht so bewandert... Macht nichts... ich auch nicht ;-) Gruß Ingo
@rudi (der erste :) Habe es glaube ich jetzt rausbekommen, ich verwende ja noch einen 3.3v spannungsregler für den xport. Wenn ich vcc vom regulator abtrenne stimmen alle temperaturen wieder. Allerdings ist das modul im moment dann sinnfrei, da keine kommunikation. Ich denke ich werfe den kram mit dem xport weg und mache ein reines rs232 modul, das kann sich dann jeder nachbauen der es braucht. A propos: ich habe firmware version 4.00, eben nachgeschaut. falls das irgendwann mal was zu bedeuten hat :) @all: wiki geht jetzt wieder und ist nebenbei auf den aktuellen Stand gebracht worden. Wer sich an der Doku beteiligen mag, der kann sich dort gerne registrieren und selbst mit daran arbeiten. Auf der Hauptseite http://wiki.neo-soft.org/index.php/Heizungsschnittstelle habe ich einen Hinweis "Aktualität der Inhalte: 2010 02 13". Dieser bezieht sich auf den Letzten aus diesem Thread entnommenen Informationsstand, diesen bitte nicht verändern, da ich sonst beim nachtragen von Informationen durcheinander komme.... Mal sehen, ich habe wieder in absehbarer Zeit mehr Luft für Basteleien, ich halte euch auf dem Laufenden, wenn ich Neuigkeiten habe. Auf Grund der kranken Temperaturen habe ich seit wochen keine Lust mich laenger in meiner Werkstatt aufzuhalten (nicht beheizt), weshalb ich zzt etwas "eingeschlafen" wirke. Aber Frühling ist ja bald in Sicht ;)
> Ich seh da grad deine Vorlauftemperatur & Warmwasser. Kann es sein das > die Pumpe deiner Heizung dein WW in den Vorlauf der Heizung drückt ? Ich glaube das passiert ohne Mitwirkung der Pumpe. Wir haben teilweise sehr dicke Heizungsrohre und die Rueckstauklappe wurde wegen Laermbelaestigung entfernt. Im Sommer trenne ich die Heizung manuell. Finde ich faszinierend, dass Du sowas ablesen kannst :)
@ IngoF > Die Sende- und Empfangsdaten sind doch nur auf einer Leitung. Man könnte > höchstens die Schaltung so modifizieren dass der Empfangsteil > abgeschaltet wird wenn die Daten gesendet werden. Aber denke das kann > man doch auch in der Software des ATMega8 machen.. Dann den Sender, da der Strom vom Pegel auf dem Bus abhängt. Bleibt noch die Frage was passiert wenn der Sender eingeschaltet wird und eine andere Einheit anfängt zu senden.
Angehängte Dateien:
-
2107.png
14 KB
> Ich glaube das passiert ohne Mitwirkung der Pumpe. Wir haben teilweise > sehr dicke Heizungsrohre und die Rueckstauklappe wurde wegen > Laermbelaestigung entfernt. Im Sommer trenne ich die Heizung manuell. > Finde ich faszinierend, dass Du sowas ablesen kannst :) Nein, ich habe da nicht drauf geachtet, mir kam es nur komisch vor das das WW so oft geladen wird. Der erwähnte Freund hat dann nochmal drüber gegrübelt. Was ist an einer Rückstauklappe so laut ??? Wäre mal interessant ob die überhaupt etwas bringt. Besser wäre natürlich ein Mischer und keine zwei Pumpen am gleichen Strang.
Hallo Rudi, > Dann den Sender, da der Strom vom Pegel auf dem Bus abhängt. Bleibt noch > die Frage was passiert wenn der Sender eingeschaltet wird und eine > andere Einheit anfängt zu senden. das kann ja nicht passieren weil die Busteilnehmer nur auf das Polling antworten. Wenn jetzt natürlich der ATMega8 einfach drauf los sendet ohne auf sein Polling zu warten wird es natürlich Probleme geben. Schätze dass dann die fehlerhaften Telegramme ignoriert werden dank der ominösen Prüfsumme. Gruß Ingo
IngoF schrieb:
>> Dann den Sender
habe das vermutlich falsch verstanden. Den Sender kann man ja schlecht
abschalten wenn er senden soll... Dachte höchstens den Empfänger, damit
die selbst gesendeten Daten nicht wieder empfangen werden.
Aber das könnte man ja im Atmega8 besser machen. Einfach nach dem Senden
die eigelesenen Daten irgnorieren. Kann man auch notfalls an der
eigenene Adresse erkennen...
Gruß
Ingo
@IngoF > habe das vermutlich falsch verstanden. Den Sender kann man ja schlecht > abschalten wenn er senden soll... Dachte höchstens den Empfänger, damit > die selbst gesendeten Daten nicht wieder empfangen werden. Den Empfänger kann man schon anlassen, dann sieht man direkt ob die Daten sauber gesendet wurden und es keine Buskollision gab.
Hallo, welcher Händler bietet denn den verwendeten ADCMP370 an? Oder gibt es Vergleichstypen? Ich kann da nichts finden! Gruß Martin
> welcher Händler bietet denn den verwendeten ADCMP370 an? Oder gibt es > Vergleichstypen? Ich kann da nichts finden! Den kannst du bei Analog sampeln oder bei digikey gibt es den auch. Andere Möglichkeit wäre ein Komparator der über seiner Versorgungsspannung Signale am Eingang verträgt. Eine andere ungetestet Methode wäre auch eine z-diode (etwa 11.5V) in Reihe und dann an einen Opto., evtl. noch mit Transistor zwischen. Das wäre dann die sichere low-cost Variante.
Hallo zusammen, ich bin gerade über diese Diskussion gestolpert und fasziniert darüber was Ihr erreicht habt :-) Ich habe ein Buderus Heizung mit BC10 und RC35. Die Anlage ist nett hat aber ein Problem. Alle paar Wochen läuft sie in einen Fehler, gefühlt so ca. 10 Mal im Jahr. Das BC10 zeigt Fehlercode 6A (Handbuch: Brenner kann nicht gezündet werden) und der Warmwasserspeicher kühlt langsam aus. Man merkt das dann dadurch dass kein heisses Wasser mehr kommt... Ich würde gerne das Verhalten der Anlage über längere Zeit mitschreiben um zu schauen woran das wohl liegen könnte. Gibt der BC10 über die Service-Key-Schnittstelle auch Fehler aus? Dazu habe ich hier noch nix gesehen. Nach einem A6-Fehler kommt man über einen Reset (Taster an der BC10) wieder in den Normalzustand. Kann man den reset auch über die Service-Key-Schnittstelle auslösen? Viele Grüße, Bernd
> Nach einem A6-Fehler kommt man über einen Reset (Taster an der BC10) > wieder in den Normalzustand. Kann man den reset auch über die > Service-Key-Schnittstelle auslösen? Wie wäre es den Heizungsfritzen an das Gerät zu zitieren ?
Schon drei mal gemacht. Gibt immer eine Riesenbaustelle. Nutzt aber nix weil der Fehler nie auftritt wenn die da sind. Und die stellen nicht einen Monat einen Rechner hier hin um mitzuschreiben was die Kiste macht. Und ich werde deswegen den Brenner nicht rausreißen lassen. Deshalb: Nase voll und Selbsthilfe... Viele Grüße, Bernd
Bei einem defekten Brenner oder defekter Flammenerkennung helfen dir die Daten auch nicht. Es gab bei B. eine Rückrufaktion für einige Brenner, evtl. gilt das auch für dich !? Die letzte Fehlermeldung ist in den Daten, wie auch im Monitormenü am Display. > Nach einem A6-Fehler kommt man über einen Reset (Taster an der BC10) > wieder in den Normalzustand. Kann man den reset auch über die > Service-Key-Schnittstelle auslösen? Evtl. über SSR Heizung aus/an ?
Hat jetzt nicht mehr zu viel mit dem Thema zu tun... Ich glaube nicht dass der Brenner defekt ist. Der zündet problemlos einige 100 Mal (einige 1000 Mail?) im Jahr. Google sagt mir dass der 6A Fehler verschiedenste Ursachen haben kann, von Abgas in der Zuluft bis kein Gas. Vielleicht finde ich ja ein Muster in den Daten. Jedenfalls passiert das fast immer nachts, die morgentliche Dusche danach ist erfrischend. Viele Grüße, Bernd
Kannst du die Heizung auch ohne Reset zum laufen bewegen ? Ich denke per Software könnte man evtl. den Fehlerspeicher löschen.
Die Bedienungsanleitung sagt "Bei 6A Reset drücken". 6A kommt wenn die Elektronik es mehrmals hintereinander nicht geschafft hat den Brenner zu zünden. Die Kiste geht dann schlafen weil sie nicht weiss was sie machen soll, eine Heizung die nicht heizen kann hat eine Identitätskrise. Wenn ich dann einige Stunden später komme und Reset drücke dann springt der Brenner (bisher immer) problemlos an. Wie komme ich denn an den Fehlerspeicher? Über das RC35 Modul?
Logamatic 2107/KM271 Nur als Info: hab an dem KM271 fhem Modul weitergebastelt: Ich kann (wie oben schon erwaehnt) bestaetigen: nach dem senden der "logmode" Aufforderung sendet der 2107 erst ca 60 Stueck 6-er Bloecke aus dem Adressbereich 0000 bis 01e0, dann die schon bekannten einnzelnen Bytes aus dem Bereich 8000-8940 und dann die vom chipshuffler erwaehnten "unbekannten" 914x und 03xx Daten. Ich habe durch drehen aller Knoepfe meiner Logamatic ca 20 Bytes aus dem ersten 60x6 Block entschluesselt. Weiterhin kann das fhem Modul die vom vom Chipshuffler beschriebenen Werte auch aendern. Siehe auch: http://cvs.berlios.de/cgi-bin/viewvc.cgi/fhem/fhem/FHEM/00_KM271.pm?revision=1.3&view=markup Gruss, Rudi
BerndV schrieb:
> Wie komme ich denn an den Fehlerspeicher? Über das RC35 Modul?
Über das Service-Menü. Bei meiner RC30 muss man drei Tasten gleichzeitig
drücken. Soweit ich weiß die ganz linke und die beiden rechten. Evtl.
mal in der Bedienungsanleitung nachsehen. Allerdings kann man dort nur
die Fehler sehen. Vielleicht kann man die dort auch herauslöschen.
Wenn das helfen sollte kann man bestimmt auch eine Softwarelösung dafür
finden. Ist allerdings nur ein herumbasteln an den Symptomen wenn es
klappen sollte.
Vermute allerdings dass Du wirklich den Reset-Schalter an der Anlage
drücken musst. Dann kann eine Softwarelösung wohl kaum helfen.
Allerdings gibt es (noch) das Problem dass die Prüfsumme vom Protokoll
her nicht bekannt ist. Notfalls müsste man die Software-Reset-Prozedur
der RC35 mitschneiden und von einer Elektronik mit oder ohne PC
automatisch schicken.
Man könnte die Daten am Bus mitloggen und eventuell die Fehlermeldung
darin finden. Was Dir vermutlich auch nichts helfen wird
Mit der Schaltung von Rudi oder mir könntest Du Die Daten aufzeichen und
Dir ansehen. Habe inzwischen meine Schaltung wieder ein wenig geändert.
Ist vermutlich unwahrscheinlich den Fehler zu finden. Aber vielleicht
hilft es ja trotzdem.
Wie gesagt sind alles nur Vermutungen....
Falls Du das mal versuchen möchtest und nicht mit dem lötkolben umgehen
kannst oder möchtest, kann ich dir die Schaltung zum selbstkostenpreis
zusammenbauen und mit Software zuschicken. Allerdings muss dann immer
ein PC rund um die Uhr laufen.
Gruß
Ingo
Ich wollte mal meine Projekte zur Verfüging stellen. ETH_M32 (URadig) ist für das Pollin-AVR-Net-IO Board. Läuft bei mir aber mit einem Atmega644 statt Atmega32. Wenn man sich per Telnet drauf verbindet werden die empfangenen Telegramme über die Telnet-Verbindung weitergeben. 1-Byte-Telegramme werden aus Performancegründen nicht versendet und die Daten gehen nicht binär sondern als Hex-Text über die Leitung (Telegramm-Ende CR/LF). War für mich einfacher für das Debugging und die Auswertung als das binäre Protokoll wie von Rudi. DAC1 wird als Ausgang für die Empfangs-LED verwendet. EmsBusReceiver ist der Code von Rudi für Atmega8 (binäres Protokoll). Als Hardware verwende ich das Pollin-AVR-Evaluationsboard. Am Pollin-Board gehe ich mit der Empfängerplatine direkt auf den RS232 Stecker, deshalb habe ich an der Platine +/- Eingang getauscht damit mir der OP das Signal invertiert. Ein Problem habe ich noch mit der Auswertung der daten vom UBA3. Die Warmwassertemperatur geht manchmal für 1 Telegramm auf (immer) 25.7 Grad. Brennerstatus stimmt auch nicht. Die Daten für den Wasserdruck liegen bei mir auch auf anderen Stellen im Telegramm. Kann mir hier jemand nochmal seine komplette Auswertungsroutine posten? Mein Eindruck ist das die Daten in der Excel-Liste teilweise nicht stimmen. Gruss Matthias
Beitrag "Re: Logamatic 2107 Schnittstelle" Der Druck ist an Stelle 21. Poste doch mal eins von deinen falschen Telegrammen. Evtl. sind es einfach nur Übertragungsfehler.
Hallo Rudi Das Telegramm sieht bei mir so aus (letztes Byte ist Anzahl der Zeichen im Telegramm) Das Telegramm ist also immer nur 18 Byte gross. Der Druck ist an Stelle 13. 080018003C02640125800201010F48C8028E12 080018003C02640125800201010F48C802C712 080018003C02640125800201010F48C802EA12 080018003C02640125800201011048C8021412 080018003C02640125800201011048C8022112 080018003C02640125800201011048C8022D12 080018003C02640125800201011048C8022D12 080018003C02640125800201011048C8023712 080018003C02640125800201011048C8028212 080018003C02640125800201011048C8028F12 080018003C02640125800201011048C8029B12 080018003C02640125800201011048C802A412 080018003C02640125800201011048C802BD12 080018003C02640125800201011048C802BD12 080018003C02640125800201011048C802E512 080018003C02640125800202011048C8027712 080018003C0264012C800102000D4C1C027512 080018003C0264012D800102000E4C1C02F012 080018003C0264012D800102000F4C1C02E412 080018003C0264012D800200000D4C1C025F12 Bei der Aussentemp. konnte ich dagegen noch keine "Fehler" feststellen. 080019000002140000640802370002A006002313 08001900000B2C00001F0802120002BD06026413 08001900000C1F0000270802160002C106029013 08001900000C2300002E0802190002C406024113 08001900000C270000210802130002BE06024C13 08001900000C3700001E0802110002BC0602E213 0800190000895A00001E08022F00029C06012113 080019000089800000000802A20002C306001813 0800190000898000001E08022D00029A06012613 Die Daten vom WM10 und RC35 passen auch. Gruss Matthias
Hallo Matthias, habe vorgestern die Auswertung der Satusbytes 10 und 11 vom Telegramm 080018 bei mir eingebaut. Ich musste hinterher die Bytes 11 und 10 tauschen. Vielleicht mal ausprobieren die Bytes zu tauschen. Habe nicht mehr nachgeschaut obe es jetzt von mir ein Programmierfehler war oder wirklich die Exeltabelle die Bytes 10 und 11 vertauscht hat. Ich meinte die Exel-Tabelle die die ganzen Telegramme auswertet werden und 5 Megabyte hat oder noch größer ist. Die Telegramme kann ich imm Moment nicht mit meinen vergleichen. Gruß Ingo
Hallo Ingo, An einen Byte-Verdereher glaube ich nicht, da die Werte ja zur Anzeige im RC35 passen. Komisch ist das ich nur ein 18-Byte-Telegramm habe (ganz selten war's mal ein 17-Byte-Tele, das war dann wohl ein Übertragungsfehler). Vielleicht muss ich auch nochmal meine Empfängerplatine optimieren. Verwende einen LM393, die Signale nehme ich mittels Spannungsteiler vom Bus ab damit mein Eingang kleiner 5V ist (Vcc vom LM393). Allerdings würde mich halt wundern, das das Telegramm immer so schön reproduzierbar ist. Gruss Matthias
Warum sind deine Nachrichten so kurz ?
1 | 08 00 18 00 31 01 E4 64 23 09 01 25 60 80 00 02 03 01 4F 00 A4 0E 2D 48 00 C8 00 02 00 DF |
2 | |
3 | 08 00 18 00 3C 02 64 01 2D 80 02 00 00 0D 4C 1C 02 5F 12 |
4 | |
5 | 08 00 19 00 00 5C 01 DF 80 00 00 00 00 37 00 D1 1F 0C DB 88 00 00 00 0B 40 DD 00 C3 EA 14 |
6 | |
7 | 08 00 19 00 00 02 14 00 00 64 08 02 37 00 02 A0 06 00 23 13 |
Hallo Matthias, ich habe auch einen LM393 in meiner Schaltung. Klappt eigentlich problemlos. @Rudi, meinte nur die Bytes 10 und 11 der Rest wird wohl stimmen.. Aber wie gesagt, kann auch ein Programmierfehler von mir gewesen sein den ich dann glatt gezogen habe. Gruß Ingo
@Rudi Mit der Telegrammlänge wunder ich mich auch. Was hast Du den für Komponenten-Versionen? Bei mir ist: RC35 1.08 UBA3 3.06 BCM Version 12 BCM Nummer 1072 BC10 2.03 WM10 2.0 Werde aber auch noch mal in meiner Netio-Software schauen ob ich da etwa irgendwas versemmel... @ Ingo Dneke auch das der LM393 gut funktioniert, da die Kommunikation reproduzierbar ist. Gruss Matthias
@Matthias Ein anderes Protokoll in Abhängigkeit von der Versionsnummer kann ich mir nicht wirklich vorstellen. Kommt die Länge vom Pollin-AVR-Evaluationsboard oder berechnest du die neu ? Kannst du mal ein Log mehrerer Nachrichten posten (mit Space zwischen den Bytes bitte) ? Ich habe hier eine RC30.
Hallo Rudi, die Länge berechne ich beim Empfang wenn der Frameerror kommt auf dem Atmega, das ist prinzipiell das Verfahren aus deinem Atmega-Code. Die Logdaten zeichne ich heute Abend mal auf. Das unterschiedliche Versionen ein unterschiedliches Protokoll fahren sollten käme mir auch seltsam vor (zumindest bei Heiztechnik). Allerdings finde ich schon komisch das bei mir auch der Heizungsdruck reproduzierbar auf anderen Adressen liegt. Gruss Matthias
Hallo Rudi, anbei das Log (ca. 2h 18:15-20:30) mit Spaces. Bzgl. der Datenerfassung hab ich nochmal geschaut. Sollte eigentlich so stimmen. Der Netio erfasst direkt die Telegramme und sendet sie per telnet. Am Anfang hatte ich etwas Probleme mit der Performance, deshalb sende ich nicht mehr die 1-Byte Telegramme. Muss es aber nochmal mit dem Eval-board versuchen (deine Version - Ausgabe über Uart) und schauen, ob ich damit andere Daten bekomme. Gruss Matthias
@Matthias Die Daten werden offensichtlich wirklich in einem anderen Format geschickt. Hast du die Hard-/Software kontrolliert ? Hier meine Versionen: UBA3/MC10 (Universeller Brennerautomat/Mastercontroller) - 8 - V3.02 BC10 (Basiscontroller) - 9 - V2.02 RC30 (Raumcontroller) - 16 - V2.08 Version 3 KIM (Kesselidentifikationsmodul) 1051
Angehängte Dateien:
-
rc30_kl1.png
740 KB
Anbei die Versorgung und Datenschnittstelle einer RC30. Alles über 2 Kontakte.
@Rudi Hallo Rudi, vielen Dank für dein Infos. Habe bei mir in meiner jetzigen Konfiguration alles geprüft, scheint OK zu sein. Ich werde jetzt nochmal die Telegramme direkt über die RS232 auslesen (deine Atmega8-Software). Allerdings fehlt mir gerade etwas die Zeit, deshalb kann es noch ein paar Tage dauern. Ich melde mich sobald ich es getestet habe. Gruss Matthias
@IngoF Bist du mit deiner Sendefunktionalität weiter gekommen ? Ich habe es jetzt mit zwei Fets und einer Z-Diode aufgebaut. Senden funktioniert, nur wird die Nachricht offensichtlich nicht ordentlich empfangen. Entweder ich bekomme keine Antwort oder eine Falsche. Ich habe zum Testen die 10 88 ... Nachricht verwendet.
Nein, noch nicht wirklich.. Habe mich an der Prüfsumme versucht und aber nur ein wenig weiter gekommen.. Mit praktischen Versuchen habe ich noch nichts versucht... Vielleicht sollte ich doch den Microcontroller zum senden nehmen, Dann muss ich aber erst noch mal Dein Programm in Assembler nachschrieben oder noch mal von vorne anfangen... Gruß Ingo
Also es scheint schon mal ein "normales" XOR zu sein. Und nach der Berechnung wird die Prüfsumme ein Bit nach rechts rotiert. Aber bei Bytes mit gesetztem MSB werden die beiden mittleren Bits getauscht. Aber irgendwie Ist das noch nicht ganz OK so... Vielleicht hat ja noch jemand eine Idee... Gruß Ingo
@IngoF Senden funktioniert nur mit gleichzeitigem RX. Es kann auch nicht mit einer vorhandenen Adresse gesendet werden. Sendet man z.B. einfach ein 0x10 Antwortet die vorhandene 0x10 mit 0x10. Kollisionen werden über das RX erkannt, da der Bus bei einem "high" released wird ein ein anderer Sender den Bus auf "low" halten würde. Das mit der CRC hört sich doch schonmal gut an. Bei mir sah es etwas anders aus. Die oberen 4 Bits gingen nur in die oberen Bits der CRC ein. Die unteren 4 Bits in die unteren 4 Bits der CRC. Ich habe aber nur einen Nachrichtentyp getestet. Mit einer vorhandenen Sendefunktion sollte es evtl. einfacher werden.
Soweit ich herausgefunden habe müsste man auch erst auf sein Polling warten. Und kann dann erst senden. Also 0x90 0x00 ist das Polling für die RC30/35 die mit 0x10 0x00 antwortet, oder noch Daten hinterhersendet. Ich hatte bei drei verschiedenen Telegrammen die Bits getestet. Dann wurde immer rechts rotiert. Also ging auf die Prüfsumme Bit0 das Bit0 vom letzen Byte, Das Bit1 vom vorletzten Byte , das Bit2 vom drittletzen Byte ein. Soweit ich mitbekommen habe schien die Adresse nicht mit in die Berechnung gegangen zu sein. Immer nur die Daten nach den Quell und Zieladresse. Die Prüfsumme von den Betriebsstunden kann man relativ gut berechnen. einfach 0x60 XOR mit dem erten Byte, dannach dann das Zwischenergebnis rotieren und dann XOR dem aktuellen Byte.. Das klappt dann bei allen Telegrammen. Außnahme sind die Telegramme die an dem vorletzten Byte das MSB gesetzt haben. Wäre ja mal ganz interessant zu wissen ob in der RC30/35 dann ein neuer Bus-Teilnehmer auftaucht wenn man das Polling immer mit der Adresse beantwortet. Vielleicht kann man schon mal herausfinden welche Adressen für welche Module vorgesehen sind. Gruß Ingo
@IngoF So ganz komme ich bei deiner Berechnung nicht mit. Mal ein Bsp.: CRC = 0xE9 08 10 14 00 1E 64 00 <E9> crc = 0x60 crc = crc ^ 0x08 crc = crc >> 1 usw. bis 0x00 Da komme ich auf 0x1A
Angehängte Dateien:
-
crc.PNG
72 KB
Genau so... hier mal meine Beispiel-Berechnung mit Excel. Wer kein Excel kann sich das Bildchen ansehen... bei den Telegrammen mit größer 0x7f habe ich als Startwert 0x00 genommen. Die Prüfsummen sind in der Fett gedruckt. Bei anderen Telegrammen hat es aber nicht geklappt.. Aber immerhin schon mal ein weiterer Schritt in die Richtige Richtung. Habe alle Telegramme mitgeloggt und dann die passenden Telegramme ausgesucht und zum Berechnen genommen.
Aha, mhh. Ich habe jetzt folgendes probiert, mit allen Bytes gerechnet bis auf die CRC. crc = 0x60 crc = crc ^ data if crc & 0x80 => crc = crc ^ 0x09 usw. Der Stern hinter dem Byte bedeutet es wurde mit dem Byte gerechnet und ein # bedeutet ein xor 0x09 und ein ! bedeutet kein xor 0x09. Die finale CRC wird mit 0xff xort. Stimmt auch fuer eine Gruppe bis es wieder nicht stimmt ;-) Ich glaube die benutzen doch ne Tabelle oder es geht noch etwas anderes mit rein. Evtl. hilft es ja. FOUND: 08 * ! 10 * ! 14 * ! 00 * ! 1E * ! 63 * ! DE * # 39 00 39 FOUND: 08 * ! 10 * ! 14 * ! 00 * ! 1E * ! 63 * ! E0 * # 07 00 07 FOUND: 08 * ! 10 * ! 14 * ! 00 * ! 1E * ! 63 * ! E2 * # 05 00 05 FOUND: 08 * ! 10 * ! 14 * ! 00 * ! 1E * ! 63 * ! E4 * # 03 00 03 FOUND: 08 * ! 10 * ! 14 * ! 00 * ! 1E * ! 63 * ! E6 * # 01 00 01 FOUND: 08 * ! 10 * ! 14 * ! 00 * ! 1E * ! 63 * ! E8 * # 0F 00 0F FOUND: 08 * ! 10 * ! 14 * ! 00 * ! 1E * ! 63 * ! EC * # 0B 00 0B FOUND: 08 * ! 10 * ! 14 * ! 00 * ! 1E * ! 63 * ! EE * # 09 00 09 FOUND: 08 * ! 10 * ! 14 * ! 00 * ! 1E * ! 63 * ! F0 * # 17 00 17 FOUND: 08 * ! 10 * ! 14 * ! 00 * ! 1E * ! 63 * ! F2 * # 15 00 15 FOUND: 08 * ! 10 * ! 14 * ! 00 * ! 1E * ! 63 * ! F4 * # 13 00 13 FOUND: 08 * ! 10 * ! 14 * ! 00 * ! 1E * ! 63 * ! F6 * # 11 00 11 FOUND: 08 * ! 10 * ! 14 * ! 00 * ! 1E * ! 63 * ! F8 * # 1F 00 1F FOUND: 08 * ! 10 * ! 14 * ! 00 * ! 1E * ! 63 * ! FA * # 1D 00 1D FOUND: 08 * ! 10 * ! 14 * ! 00 * ! 1E * ! 63 * ! FC * # 1B 00 1B FOUND: 08 * ! 10 * ! 14 * ! 00 * ! 1E * ! 63 * ! FE * # 19 00 19 FOUND: 08 * ! 10 * ! 14 * ! 00 * ! 1E * ! 64 * ! 00 * ! E9 00 E9 FOUND: 08 * ! 10 * ! 14 * ! 00 * ! 1E * ! 64 * ! 02 * ! EB 00 EB FOUND: 08 * ! 10 * ! 14 * ! 00 * ! 1E * ! 64 * ! 04 * ! ED 00 ED FOUND: 08 * ! 10 * ! 14 * ! 00 * ! 1E * ! 64 * ! 06 * ! EF 00 EF FOUND: 08 * ! 10 * ! 14 * ! 00 * ! 1E * ! 64 * ! 08 * ! E1 00 E1 FOUND: 08 * ! 10 * ! 14 * ! 00 * ! 1E * ! 64 * ! 0C * ! E5 00 E5 FOUND: 08 * ! 10 * ! 14 * ! 00 * ! 1E * ! 64 * ! 0E * ! E7 00 E7 FOUND: 08 * ! 10 * ! 14 * ! 00 * ! 1E * ! 64 * ! 10 * ! F9 00 F9 FOUND: 08 * ! 10 * ! 14 * ! 00 * ! 1E * ! 64 * ! 14 * ! FD 00 FD FOUND: 08 * ! 10 * ! 14 * ! 00 * ! 1E * ! 64 * ! 16 * ! FF 00 FF FOUND: 08 * ! 10 * ! 14 * ! 00 * ! 1E * ! 64 * ! 18 * ! F1 00 F1 FOUND: 08 * ! 10 * ! 14 * ! 00 * ! 1E * ! 64 * ! 1A * ! F3 00 F3 FOUND: 08 * ! 10 * ! 14 * ! 00 * ! 1E * ! 64 * ! 1C * ! F5 00 F5 FOUND: 08 * ! 10 * ! 14 * ! 00 * ! 1E * ! 64 * ! 1E * ! F7 00 F7 FOUND: 08 * ! 10 * ! 14 * ! 00 * ! 1E * ! 64 * ! 20 * ! C9 00 C9 FOUND: 08 * ! 10 * ! 14 * ! 00 * ! 1E * ! 64 * ! 22 * ! CB 00 CB FOUND: 08 * ! 10 * ! 14 * ! 00 * ! 1E * ! 64 * ! 24 * ! CD 00 CD FOUND: 08 * ! 10 * ! 14 * ! 00 * ! 1E * ! 64 * ! 26 * ! CF 00 CF FOUND: 08 * ! 10 * ! 14 * ! 00 * ! 1E * ! 64 * ! 28 * ! C1 00 C1 FOUND: 08 * ! 10 * ! 14 * ! 00 * ! 1E * ! 64 * ! 2A * ! C3 00 C3 FOUND: 08 * ! 10 * ! 14 * ! 00 * ! 1E * ! 64 * ! 2C * ! C5 00 C5 FOUND: 08 * ! 10 * ! 14 * ! 00 * ! 1E * ! 64 * ! 2E * ! C7 00 C7 FOUND: 08 * ! 10 * ! 14 * ! 00 * ! 1E * ! 64 * ! 30 * ! D9 00 D9 FOUND: 08 * ! 10 * ! 14 * ! 00 * ! 1E * ! 64 * ! 32 * ! DB 00 DB FOUND: 08 * ! 10 * ! 14 * ! 00 * ! 1E * ! 64 * ! 34 * ! DD 00 DD FOUND: 08 * ! 10 * ! 14 * ! 00 * ! 1E * ! 64 * ! 36 * ! DF 00 DF FOUND: 08 * ! 10 * ! 14 * ! 00 * ! 1E * ! 64 * ! 38 * ! D1 00 D1 FOUND: 08 * ! 10 * ! 14 * ! 00 * ! 1E * ! 64 * ! 3A * ! D3 00 D3 FOUND: 08 * ! 10 * ! 14 * ! 00 * ! 1E * ! 64 * ! 3C * ! D5 00 D5 FOUND: 08 * ! 10 * ! 14 * ! 00 * ! 1E * ! 64 * ! 3E * ! D7 00 D7 FOUND: 08 * ! 10 * ! 14 * ! 00 * ! 1E * ! 64 * ! 42 * ! AB 00 AB FOUND: 08 * ! 10 * ! 14 * ! 00 * ! 1E * ! 64 * ! 44 * ! AD 00 AD FOUND: 08 * ! 10 * ! 14 * ! 00 * ! 1E * ! 64 * ! 46 * ! AF 00 AF FOUND: 08 * ! 10 * ! 14 * ! 00 * ! 1E * ! 64 * ! 48 * ! A1 00 A1 FOUND: 08 * ! 10 * ! 14 * ! 00 * ! 1E * ! 64 * ! 4A * ! A3 00 A3 FOUND: 08 * ! 10 * ! 14 * ! 00 * ! 1E * ! 64 * ! 4C * ! A5 00 A5 FOUND: 08 * ! 10 * ! 14 * ! 00 * ! 1E * ! 64 * ! 4E * ! A7 00 A7 FOUND: 08 * ! 10 * ! 14 * ! 00 * ! 1E * ! 64 * ! 50 * ! B9 00 B9 FOUND: 08 * ! 10 * ! 14 * ! 00 * ! 1E * ! 64 * ! 52 * ! BB 00 BB FOUND: 08 * ! 10 * ! 14 * ! 00 * ! 1E * ! 64 * ! 54 * ! BD 00 BD FOUND: 08 * ! 10 * ! 14 * ! 00 * ! 1E * ! 64 * ! 56 * ! BF 00 BF FOUND: 08 * ! 10 * ! 14 * ! 00 * ! 1E * ! 64 * ! 58 * ! B1 00 B1 FOUND: 08 * ! 10 * ! 14 * ! 00 * ! 1E * ! 64 * ! 5A * ! B3 00 B3 FOUND: 08 * ! 10 * ! 14 * ! 00 * ! 1E * ! 64 * ! 5D * ! B4 00 B4 FOUND: 08 * ! 10 * ! 14 * ! 00 * ! 1E * ! 64 * ! 5F * ! B6 00 B6 FOUND: 08 * ! 10 * ! 14 * ! 00 * ! 1E * ! 64 * ! 61 * ! 88 00 88 FOUND: 08 * ! 10 * ! 14 * ! 00 * ! 1E * ! 64 * ! 63 * ! 8A 00 8A FOUND: 08 * ! 10 * ! 14 * ! 00 * ! 1E * ! 64 * ! 65 * ! 8C 00 8C FOUND: 08 * ! 10 * ! 14 * ! 00 * ! 1E * ! 64 * ! 67 * ! 8E 00 8E FOUND: 08 * ! 10 * ! 14 * ! 00 * ! 1E * ! 64 * ! 69 * ! 80 00 80 FOUND: 08 * ! 10 * ! 14 * ! 00 * ! 1E * ! 64 * ! 6B * ! 82 00 82 FOUND: 08 * ! 10 * ! 14 * ! 00 * ! 1E * ! 64 * ! 6D * ! 84 00 84 FOUND: 08 * ! 10 * ! 14 * ! 00 * ! 1E * ! 64 * ! 6F * ! 86 00 86 FOUND: 08 * ! 10 * ! 14 * ! 00 * ! 1E * ! 64 * ! 71 * ! 98 00 98 FOUND: 08 * ! 10 * ! 14 * ! 00 * ! 1E * ! 64 * ! 73 * ! 9A 00 9A FOUND: 08 * ! 10 * ! 14 * ! 00 * ! 1E * ! 64 * ! 75 * ! 9C 00 9C FOUND: 08 * ! 10 * ! 14 * ! 00 * ! 1E * ! 64 * ! 77 * ! 9E 00 9E FOUND: 08 * ! 10 * ! 14 * ! 00 * ! 1E * ! 64 * ! 79 * ! 90 00 90 FOUND: 08 * ! 10 * ! 14 * ! 00 * ! 1E * ! 64 * ! 7B * ! 92 00 92 FOUND: 08 * ! 10 * ! 14 * ! 00 * ! 1E * ! 64 * ! 7D * ! 94 00 94 FOUND: 08 * ! 10 * ! 14 * ! 00 * ! 1E * ! 64 * ! 7F * ! 96 00 96 FOUND: 08 * ! 10 * ! 14 * ! 00 * ! 1E * ! 64 * ! 81 * # 68 00 61 FOUND: 08 * ! 10 * ! 14 * ! 00 * ! 1E * ! 64 * ! 83 * # 6A 00 63 FOUND: 08 * ! 10 * ! 14 * ! 00 * ! 1E * ! 64 * ! 85 * # 6C 00 65 FOUND: 08 * ! 10 * ! 14 * ! 00 * ! 1E * ! 64 * ! 87 * # 6E 00 67 FOUND: 08 * ! 10 * ! 14 * ! 00 * ! 1E * ! 64 * ! 89 * # 60 00 69
Ja, habe ich ja gesagt... bei den Telegrammen mit 0x80 oder größer muss genau bei dem XOR wohl die beiden mittleren Bits getauscht werden. Oder man nimmt den STartwert 0x00, dann stimmt es auch wieder... ABer wie gesagt bei den anderen Telegrammtypen am Anfang der Excel-Datei stimmt es auch nicht.. Also wie gesagt.. Ich habe für etwa einen Monat die Telegramme mitgeloggt und dann immer zwei Telegrammpärchen ausgesucht wo nur ein einziges Bit geändert wurde. Da habe ich dann bei allen Telegrammen herausgefunden dass die Bytes immer bei jedem XOR verschoben sind. Auch bei anderen Telegrammtypen. Gruß Ingo
Nein, das kann ich nicht bestätigen. Mal auf die letzten Bytes und den Betriebsstundenzähler bezogen, es ändert sich bei der 0x80er Grenze (durch das Polynome) und dann noch bei einem Wechsel vom vorletzten Byte. Für mich bedeutet das eine normale CRC (Tabellenbezogen). Die Tabelle wird wohl hausbacken sein, ansonsten wäre die CRC schon klar. Bei einem Polynome von 0x09 (xort wenn das MSB in der CRC gesetzt ist) bleibt die Differenz zwischen berechneter und vorhandener CRC immer gleich, bis zu einem Wechsel des vorletzten Bytes, da es nun als Index auf einen neuen Wert in der Tabelle verweist. Da sich die Bytes davor nicht ändern ist dieser Index erstmal gleich. Teste es einfach mal ;-)
Anbei noch eine Ausgabe als Logdatei:
FOUND: 08 * ! 10 * ! 14 * ! 00 * ! 1E * ! 5E * ! 6D * ! F0 DE 21 2E
Die letzten 4 Byte:
F0 DE 21 2E
**----------CRC-1 aus dem Datenstream
**-------CRC-2 berechnet mit dem finalen XOR 0xff
**----CRC-3 ohne Polynome (einfaches XOR aller Bytes ohne finales
XOR)
**-berechneter Wert aus CRC-1 XOR 0xFF XOR CRC-2 (*1)
(*1) wobei ich grad merke das XOR 0xff hätte ich mir auch sparen können
Für mich sieht das erstmal gut aus ...
Also dass sich die Bits verschoben auf die Prüfsumme auswirken ist ganz sicher. Zumindest bei den getesteten Telegrammen. Allerdings ist es nicht so einfach passende Telegrammpärchen zu finden bei denen sich nur ein Bit ändert. Das vorletzte Tabellenblatt enthält Telegramme von Dir und Mir die wenig änderungen haben. Das letzte Tabellenblatt sind Telegramme von 0x10 0x00 0x9c bei dennen das auch zutrifft. die letzte Zeile in Rot ist nur ein XOR damit man sieht welches Bit sich ändert. Nach meiner Berechnung funktionieren bisher alle Telegramme von 0x10 0x00 0x14. Denke das ist schon mal ein kleiner Schritt in die richtige Richtung.. Nur dass man bei Telegrammen mit >0x7f einen anderen Startwert nehmen muss (>0x7f = 0x60 / <0x80 = 0x00) Das Telegramm ist eigentlich nicht sooo gut geeignet die Prüfsumme zu finden... Am besten wäre ein Telegramm bei der sich alle Werte ändern, und das so häufig vorkommt dass man genug Rohmaterial hat um zu sehen welches Bit sich wie auswirkt. Aber das gibt es ja nicht.. ABer vielleicht kann man ja durch die Sendefunktion und die Antwort durch irgendeinen Busteilnehmer so ein Telegramm finden..... Diese Verschiebung durch eine Stelle bei jedem Byte kann doch nicht durch ein Polynom kommen, oder? Kann es sein dass es doch irgendein Polynom ist, bei der dann nach jedem Byte das Zwischenergebnis rotiert wird? Aber dann würde ich doch nicht so eine "gute" CRC mit einem simplen XOR nachrechnen können. Also irgendeine Schweinerei außer das rotieren haben die noch eingebaut.
Wie sieht denn Deine Schaltung mit den FETS und der Z-Diode aus? Würde mich mal interessieren :-) Gruß Ingo
Der initiale Wert ist 0x00. Wenn bei der CRC das MSB gesetzt ist, dann wird mit 12 xort, vor dem shiften. Bei der letzten Berechnung bzw. beim letzten Byte muss vor dem XOR aufgehört werden. Damit stimmen dann ALLE CRCs ! Ingo, gute Arbeit !
> Wie sieht denn Deine Schaltung mit den FETS und der Z-Diode aus? > Würde mich mal interessieren :-) Ein P-MOSFET (20K am Gate Pullup) schaltet einen N-MOSFET (500 Ohm am Gate Pulldown) der die Masse über die Z-Diode (10V) auf den Bus schaltet. Ich habe 3 500mW parallel geschaltet, hatte keine "große". Leider ist die steigende Flanke auf dem Bus etwas langsam (die fallende Flanke nicht), evtl. gibt es da noch Probleme.
Also anstelle des Wertes, oder noch zusätzlich mit 0x12 XORen. Funktioniert es dann auch bei allen anderen Telegrammen, oder nur bei bei den Betriebstunden Telegrammen? Welcher Teil wird denn verknüpft? Alles, oder nur der Datenbereich? Kann die Flanken bei meiner Lösung leider nicht kontrollieren.. Habe leider keine Möglichkeiten mehr dazu... Gruß Ingo P.S. Hat ja auch eine Weile gedauert das rauszufinden.. nur mit den 0x80 Werten kam ich nicht so ganz weiter...
Achso... das MSB bei der Prüfsumme.... Nicht beim Datenbyte... Na dann werde ich mal testen...
Hier der Code:
1 | poly = 12 |
2 | crc1 = 0x00 |
3 | |
4 | for i in range(0,len(a)-1): |
5 | crc1 = crc1 ^ int(a[i],16) |
6 | crc2 = crc1 |
7 | if crc1 & 0x80: crc1 ^= poly |
8 | |
9 | d = 0 |
10 | if crc1 & 0x80: d = 1 |
11 | crc1 = crc1 << 1 |
12 | crc1 &= 0xfe |
13 | crc1 |= d |
14 | |
15 | => crc2 |
Ich habe mal versucht die 8 anzusprechen, aber leider nichts. Meine Nachricht: 33 88 14 00 03 6C Die Adresse kann natürlich auch falsch sein und Statusbits involvieren.
> Funktioniert es dann auch bei allen anderen Telegrammen, oder nur bei > bei den Betriebstunden Telegrammen? Bei allen ;-)
Vielleicht muss man sich ja auch erst anmelden oder die Teilnehmer nehmen nur eine bestimmte Adresse an. Jede Adresse steht ja für einen bestimmten Teilnehmer. Schätze mal die 08 ist der Master und schickt das Polling los. Also müsstest Du warten bis einmal das Telegramm 0xB3 0x00 auftaucht. Was soll dass den für ein Telegramm sein? also 33 ist der ABsender die 88 der Empfänger (0x08) mit MSB gesetzt damit es antwortet. Dann möchtest Du telegramm 0x14 (oder ist das nur ein Speicherbereich). Dannach müsste dann die Prüfsumme kommen und anschließend 0x00 mit Stopbit 0, oder also 0x33 0x88 0x14 "CRC" 0x00 Fang doch erst mal mit was einfacheren an... Versuch doch erst mal nur ein existierendes Polling zu beantwortet. Also eine Adresse die noch nicht in der RC30 als Busteilnehmer eingetragen ist. z.B die 0x21 oder 0x22 wenn die noch nicht vorhanden sind. Glaub das sollten irgendwelchen Mischer sein, oder? Also auf jedes 0xa1 0x00 mit 0x21 0x00 antworten. Also erst mal ganz ohne Prüfsumme.. Dannach müsste das Polling öfter kommen und vielleicht in der RC30 als Busteilnehmer auftauchen. Dann ist schon mal klar dass das senden funktioniert. Hoffe dass es schon reichen sollte um von der RC30 als Busteilnehmer erkannt zu werden. Nicht dass noch mehr als "anmeldung" erwartet wird. Oder vielleicht kommt dann aufeinmal eine Anfrage von irgendeinem Busteilnehmer... Gruß Ingo
Ja, mal schaun. Ich stelle den Sklaven grad auf einen AVR644p um. Der hat wenigstens 2 Uarts. Einen Timer für den Timeout will ich auch noch programmieren und dann noch die UART-Break Geschichte in Software. Hoffe das funktioniert soweit. > Was soll dass den für ein Telegramm sein? also 33 ist der ABsender die > 88 der Empfänger (0x08) mit MSB gesetzt damit es antwortet. Dann > möchtest Du telegramm 0x14 (oder ist das nur ein Speicherbereich). Das ist die Abfrage für die Betriebsstunden. Break hatte ich bisher über einen Cortex gesendet, der kann das mehr oder weniger in Hardware. Den will ich aber für den Sklaven aber nicht benutzen. Der 644er läuft jetzt nebenher und hat die Sendefunktionalität. Ich kann dann also mit 2 Geräten den Bus loggen (der "alte" M8 und der 644). > Hoffe dass es schon reichen sollte um von der RC30 als Busteilnehmer > erkannt zu werden. Nicht dass noch mehr als "anmeldung" erwartet wird. > Oder vielleicht kommt dann aufeinmal eine Anfrage von irgendeinem > Busteilnehmer... Das sollte man ja beim einschalten der Anlage direkt sehen können. Hat das mit der CRC bei dir funktioniert ?
Also. Ich warte auf ein 0x8F und antworte mit einem 0x0F 8F BRK 0F BRK FC TIMEOUT Danach kommt dann FC und ein Timeout, ist wohl sowas wie Busreset !? Das ist also erstmal falsch nehme ich an. Wenn ich kein Break sende dann bekomme ich ein Echo von der 0x0f und ein Timeout. 8F BRK 0F 0F TIMEOUT Wenn ich kein Break sende und 0x0f 0x00 sende bekomme ich: 8F BRK 0F 00 TIMEOUT Wenn ich kein Break sende und 0x0f 0x00 0xFF sende bekomme ich: 8F BRK 0F 00 FF FF TIMEOUT Also wieder ein Echo.
Hallo Rudi, Laut dem Mitschnitt hier: Beitrag "Re: Logamatic 2107 Schnittstelle" müsste auf das Polling mit Adresse und 0x00 mit Stopbit 0 geantwortet werden. Als Antwort dürfte dann eigentlich garnichts kommen. Vielleicht gibt es die Adresse ja ganricht. Versuch doch mal die 0x21 oder 0x22 wenn die Mischer nicht eingebaut sind. Was ist das denn für ein Break? Wer sendet das denn? Also wenn das Terminalprogramm am PC ein Break sendet dann wird der Sendepin für 3 Sekunden auf 0 gesetzt. Das könnte für den Bus oder den Busmaster vielleicht zuviel sein. Keine Ahnung was der AVR-Uart für ein Break sendet. Auf dem Bus wurden ja nur 9 Bit (937,5µs) lang Null gesendet Vielleicht muss der UART vom Atmega8 (oder was auch immer) entsprechend konfiguriert werden. Werde das irgendwann mal im Atmega8 in Assembler programmieren. Dummerweise hatte die Festplatte den Wochenlangen Dauerbetrieb nicht verkraftet und muss mir eine andere besorgen... Kann das im Moment leider nicht selber testen. Gruß Ingo
> Laut dem Mitschnitt hier: > Beitrag "Re: Logamatic 2107 Schnittstelle" > müsste auf das Polling mit Adresse und 0x00 mit Stopbit 0 geantwortet > werden. Ja, das habe ich versucht, aber ich bekomme auf der Leitung ein Echo. > Als Antwort dürfte dann eigentlich garnichts kommen. Hier nicht. > Vielleicht gibt es die Adresse ja ganricht. Versuch doch mal die 0x21 > oder 0x22 wenn die Mischer nicht eingebaut sind. Das habe ich versucht, gleiches Verhalten. > Was ist das denn für ein Break? Wer sendet das denn? Also wenn das > Terminalprogramm am PC ein Break sendet dann wird der Sendepin für 3 > Sekunden auf 0 gesetzt. Das könnte für den Bus oder den Busmaster > vielleicht zuviel sein. Ja, ist es. Das Break sollte in etwa 1 Frame (10Bit) lang sein, damit die UART ein negiertes Stop-Bit sieht. > Keine Ahnung was der AVR-Uart für ein Break > sendet. Auf dem Bus wurden ja nur 9 Bit (937,5µs) lang Null gesendet Ja, die 937.5uS habe ich hier in etwa auch. Beim Mega ist das etwas komplizierter, da muss TX abgeschaltet werden und dann gehts per GPIO weiter. > Vielleicht muss der UART vom Atmega8 (oder was auch immer) entsprechend > konfiguriert werden. Werde das irgendwann mal im Atmega8 in Assembler > programmieren. Dummerweise hatte die Festplatte den Wochenlangen > Dauerbetrieb nicht verkraftet und muss mir eine andere besorgen... Kann > das im Moment leider nicht selber testen. Schade, bisher habe ich hier noch keine Probleme. Anbei mal der Code in C. Ich habe intern einen Timer der mit etwa 100KHz läuft und die timer_set_wait Funktion wartet die angegebenen Ticks. Ich habe mit dem Oszi gemessen und es sieht ganz vernünftig aus. Bei der RX Funktion (nicht anbei) habe ich mir noch ein Flag für ein Bus-Free eingebaut, das wird nach einem Timeout oder Break gesetzt und beim Empfang eines neuen Bytes gelöscht. So vermeidet man Kollisionen auf dem Bus.
1 | void uart0_send_data( uint8_t * data, uint8_t len, uint8_t flag ) |
2 | {
|
3 | while(len--) |
4 | {
|
5 | /* wait two bit */ |
6 | timer_set_wait(&timer02,20UL); |
7 | |
8 | /* wait for empty data register */ |
9 | while (!(UCSR0A&_BV(UDRE0))) __asm("nop");
|
10 | /* send data */ |
11 | UDR0 = *data++; |
12 | } |
13 | |
14 | /* send break */ |
15 | if ( flag & D_DATA_FLAG_BREAK ) |
16 | {
|
17 | /* wait for tx complete */ |
18 | while (!(UCSR0A&_BV(TXC0))) __asm("nop");
|
19 | /* clear flag */ |
20 | UCSR0A|=_BV(TXC0); |
21 | /* wait one bit */ |
22 | timer_set_wait(&timer02,10UL); |
23 | /* disable uart TX operation */ |
24 | UCSR0B &= ~_BV(TXEN0); |
25 | /* set TX line low (gpio) */ |
26 | PORTD &= ~(1<<1); |
27 | /* wait 11 bit */ |
28 | timer_set_wait(&timer02,110UL); |
29 | /* set TX line high (gpio) */ |
30 | PORTD |= (1<<1); |
31 | /* enable uart TX operation */ |
32 | UCSR0B |= _BV(TXEN0); |
33 | } |
34 | } |
Rudi schrieb: > Ja, die 937.5uS habe ich hier in etwa auch. Denke mit "in etwa" meintest Du genau... Allerdings > /* wait 11 bit */ Müssten dann doch 9 Bit sein, oder? Waren doch 9600 8N1 wenn ich mich recht erinnere. Also das Startbit High dann 1 Bit warten und dann 9 Bit Low (8 Daten+1Stopbit. Keine Ahnung ob sich der Busmaster wegen so einer kleinigkeit anstellt. Vielleicht sendest Du Die Bytes ja auch zu schnell hintereinander? Soweit ich mich aber erinnere wurden von der RC30 auch die Bytes hintereinander losgeschickt. Dürfte dann eigentlich auch nicht sein. Liegt das Signal denn selbsterzeugte Break denn auch richtig an? Weiß jetzt ganricht mehr so genau ob jetzt 10V oder 15Volt auf dem Bus eine 1 oder 0 war. Normalerweise wird das Signal noch mal durch einen Treiber wie MAX232 invertiert.. Kann leider auch nur im Dunkeln herumstochern... Gruß Ingo
Achso... Wir haben ja nur im laufenden Betrieb das Polling mitgeschnibbelt.. Vielleicht ist die einmalige Anmeldeprozedur ja ganz anders und läuft nur ganz kurz nach dem einschalten der Anlage ab. Vielleicht kommt bei der erstmaligen Anmeldung ja noch irgendwas wie eine Bestätigung als z.B. das 0xfc. Kannst Du das den mal mit dem Oszilloskop vergleichen ob das gesendet wird was Du auch senden möchtest.. Gruß Ingo
> Wir haben ja nur im laufenden Betrieb das Polling mitgeschnibbelt.. > Vielleicht ist die einmalige Anmeldeprozedur ja ganz anders und läuft > nur ganz kurz nach dem einschalten der Anlage ab. Nein, da passiert nicht viel. Siehe unten, direkt die Einschaltsequenz. Das zweite FF z.B. 98 FF bedeutet Timeout, das habe ich jetzt eingebaut. > Vielleicht kommt bei der erstmaligen Anmeldung ja noch irgendwas wie > eine Bestätigung als z.B. das 0xfc. Nein. > Kannst Du das den mal mit dem Oszilloskop vergleichen ob das gesendet > wird was Du auch senden möchtest.. Das stimmt schon, ich logge mit unterschiedlichen CPUs den Bus und die sehen das gleiche. Ich denke da hilft nur ein Log vom ServiceKey. So wie ich das gesehen habe wandelt der das Protokoll von der 2107 UART auf diesen Bus. Evtl. haben wir es auch noch nicht richtig verstanden wer was sendet. Warum hat z.B. die 98 immer einen Timeout, die 88 z.B. auch, und die anderen Adressen werden immer mit BRK gesendet bzw. bestätigt. Das ist auch nicht klar.
1 | 89 00 |
2 | 09 88 04 05 01 AF 00 |
3 | 08 09 04 05 19 CB 00 |
4 | 09 88 04 0B 01 B3 00 |
5 | 08 09 04 0B 0C C2 00 |
6 | 09 88 15 00 01 E1 00 |
7 | 08 09 15 00 00 9C 00 |
8 | 09 08 16 00 FF 77 00 |
9 | 01 00 |
10 | 09 08 16 01 5A D0 00 |
11 | 01 00 |
12 | 09 08 16 03 00 8E 00 |
13 | 01 00 |
14 | 09 88 16 15 01 C7 00 |
15 | 08 09 16 15 5D 00 |
16 | 09 88 16 16 01 C1 00 |
17 | 08 09 16 16 5E 00 |
18 | 09 08 33 01 FF E1 00 |
19 | 01 00 |
20 | 09 08 33 09 00 0E 00 |
21 | 01 00 |
22 | 09 00 29 00 6B 5F 00 |
23 | 09 00 |
24 | 08 00 19 00 00 B7 00 D5 80 00 00 00 00 64 00 D3 D6 0D 0A AC 00 00 00 0B 6C 4C 00 C6 80 7A 00 |
25 | 8A 00 |
26 | 89 00 |
27 | 09 88 04 0E 01 B9 00 |
28 | 08 09 04 0E 62 00 |
29 | 09 00 |
30 | 8B 00 |
31 | 89 00 |
32 | 09 00 |
33 | 08 00 33 00 08 FF 32 FB 00 0F 00 01 46 00 FF B1 00 |
34 | 08 00 34 00 32 01 D6 01 D6 21 00 00 03 00 01 9E 60 00 0D 56 00 21 00 |
35 | 8C 00 |
36 | 89 00 |
37 | 09 00 |
38 | 8D 00 |
39 | 08 00 07 00 03 00 00 00 00 00 00 00 00 00 00 00 00 12 00 |
40 | 08 00 16 00 FF 5A 64 00 06 FA 0A 01 04 64 37 02 56 00 |
41 | 89 00 |
42 | 09 00 |
43 | 08 00 18 00 00 00 D6 00 00 00 00 24 60 80 00 01 D6 00 D6 00 00 0F 30 55 01 0E 00 00 00 09 00 |
44 | 89 00 |
45 | 09 00 |
46 | 89 00 |
47 | 09 00 |
48 | 89 00 |
49 | 09 00 |
50 | 8E 00 |
51 | 89 00 |
52 | 09 00 |
53 | 8F 00 |
54 | 89 00 |
55 | 09 00 |
56 | 89 00 |
57 | 09 00 |
58 | 89 00 |
59 | 09 00 |
60 | 90 00 |
61 | 98 FF |
62 | 89 00 |
63 | 09 00 |
64 | 91 00 |
65 | 89 00 |
66 | 09 00 |
67 | 89 00 |
68 | 09 00 |
69 | 89 00 |
70 | 09 00 |
71 | 89 00 |
72 | 09 00 |
73 | 89 00 |
74 | 09 00 |
75 | 89 00 |
76 | 09 00 |
77 | 89 00 |
78 | 09 00 |
79 | 92 00 |
80 | 89 00 |
81 | 09 00 |
82 | 93 00 |
83 | 89 00 |
84 | 09 00 |
85 | 89 00 |
86 | 09 00 |
87 | 89 00 |
88 | 09 00 |
89 | 94 00 |
90 | 89 00 |
91 | 09 00 |
92 | 95 00 |
93 | 89 00 |
94 | 09 00 |
95 | 89 00 |
96 | 09 00 |
97 | 89 00 |
98 | 09 00 |
99 | 89 00 |
100 | 09 00 |
101 | 89 00 |
102 | 09 00 |
103 | 89 00 |
104 | 09 00 |
105 | 89 00 |
106 | 09 00 |
107 | 96 00 |
108 | 89 00 |
109 | 09 00 |
110 | 97 00 |
111 | 89 00 |
112 | 09 00 |
113 | 89 00 |
114 | 09 00 |
115 | 89 00 |
116 | 09 00 |
117 | 98 00 |
118 | 89 00 |
119 | 09 00 |
120 | A0 00 |
121 | 89 00 |
122 | 09 00 |
123 | 89 00 |
124 | 09 00 |
125 | 89 00 |
126 | 09 00 |
127 | 89 00 |
128 | 09 00 |
129 | 89 00 |
130 | 09 00 |
131 | 89 00 |
132 | 09 00 |
133 | 89 00 |
134 | 09 00 |
>> Ja, die 937.5uS habe ich hier in etwa auch. >Denke mit "in etwa" meintest Du genau... ;-) Es geht an die eine Millisekunde. >> /* wait 11 bit */ > Müssten dann doch 9 Bit sein, oder? Waren doch 9600 8N1 wenn ich mich > recht erinnere. Also das Startbit High dann 1 Bit warten und dann 9 Bit > Low (8 Daten+1Stopbit. Keine Ahnung ob sich der Busmaster wegen so einer > kleinigkeit anstellt. Vielleicht sendest Du Die Bytes ja auch zu schnell > hintereinander? Soweit ich mich aber erinnere wurden von der RC30 auch > die Bytes hintereinander losgeschickt. Dürfte dann eigentlich auch nicht > sein. Du musst den Bus für 10Bit auf Low ziehen, also START 8Bit STOP sind Low. Das elfte Bit ist für den Clockjitter ;-) > Liegt das Signal denn selbsterzeugte Break denn auch richtig an? Weiß > jetzt ganricht mehr so genau ob jetzt 10V oder 15Volt auf dem Bus eine 1 > oder 0 war. Normalerweise wird das Signal noch mal durch einen Treiber > wie MAX232 invertiert.. Das liegt an, ich logge ja gleichzeitig den Bus. Mein Problem ist eher dieses "mitsenden" vom Master.
Rudi schrieb: > 98 00 Also es ist ja nicht so dass die 98 immer ein Timeout bekommt. Bisher habe ich auf meinem Bus noch nie ein Timeout sehen können. Aber ich habe auch nicht so stark danach gesucht.. Vielleicht gibt es ja trotz Polling irgendwelche Kollisonen. Die 98 FF würde ich jetzt einfach mal als Übertragungsfehler oder Kollision einordnen. Soweit ich mitbekommen habe werde bekannte Busteilnehmer häufiger abgefragt. Ein Polling für Adresse 88 habe ich z.B. noch nie gesehen. Vermutlich weil das der Busmaster ist und das Polling sendet. Warum soll er sich also selber anpollen. Danach werden fortlaufend die Adressen angepollt die noch nie geantwortet haben. Fing dann meistens mit 0x89 und dann kommen der Reihe nach 0x91, 0x92, 0x93, 0x94, 0x95, 0x96, 0x97, und 0x98. Dann war soweit ich mich erinnere erst mal eine Zeitlang Ruhe beim Polling von bisher unbeantworteten Pollings. Dann ging es nach einiger Zeit mit dem nächsten Polling-Block weiter Als 0xA0, 0xA1, ..... 0xA8, dann wieder Pause und der nächste Polling-Block war dran. Demnach hätte das Polling 0x98 dort noch garnichts zu suchen. Deshalb vermute ich wirklich einen Übertragungsfehler. Vielleicht haben die beiden Sender mitgehört und mitbekommen dass die Daten falsch übertragen wurden und haben dann die Übertragung beendet. Vielleicht gab es deswegen kein <break>. Vielleicht mal das im Auge behalten ob das Polling mit dem Timeout immer, wie hier vermutlich, zur falschen Zeit kommt. Glaub ich sollte mich mal schleunigst um eine Festplatte kümmern. Vielleicht hatte die ja auch schon eine Vorschädigung. Hatte die Festplatte gebraucht gekauft. Rudi schrieb: > Du musst den Bus für 10Bit auf Low ziehen, Ups, hatte doch glatt das Startbit vergessen... Vermutlich wird das eine Bit "zuviel" wohl keine Probleme machen... Gruß Ingo
Ingo F. schrieb: > Ein Polling für Adresse 88 habe ich z.B. noch nie > gesehen. Meinte damit das 0x88 <break> Polling und nicht das mit einem Telegramm wie 0x10 0x88 .....
> Demnach hätte das Polling 0x98 dort noch garnichts zu suchen. Deshalb > vermute ich wirklich einen Übertragungsfehler. Vielleicht haben die > beiden Sender mitgehört und mitbekommen dass die Daten falsch übertragen > wurden und haben dann die Übertragung beendet. Vielleicht gab es > deswegen kein <break>. So wie ich das sehe kommt nur bei diesen Adressen (18,88,98) ein Timeout. Anbei mal ein Log mit Zeitstempel.
1 | 1272717168.7 98 FF |
2 | 1272717171.3 98 FF |
3 | 1272717175.15 88 FF |
4 | 1272717177.27 98 FF |
5 | 1272717179.87 98 FF |
6 | 1272717182.48 98 FF |
7 | 1272717184.63 98 FF |
8 | 1272717186.38 98 FF |
9 | 1272717186.86 88 FF |
10 | 1272717188.16 98 FF |
11 | 1272717190.76 98 FF |
12 | 1272717193.36 98 FF |
13 | 1272717194.06 98 FF |
14 | 1272717195.36 98 FF |
15 | 1272717196.58 18 FF |
16 | 1272717197.43 18 FF |
17 | 1272717199.39 98 FF |
18 | 1272717199.86 98 FF |
19 | 1272717201.17 98 FF |
20 | 1272717206.73 98 FF |
21 | 1272717209.33 98 FF |
22 | 1272717214.17 98 FF |
23 | 1272717215.31 98 FF |
24 | 1272717216.61 98 FF |
25 | 1272717218.07 98 FF |
26 | 1272717220.67 88 FF |
27 | 1272717223.27 98 FF |
28 | 1272717226.69 98 FF |
29 | 1272717227.17 98 FF |
30 | 1272717228.47 98 FF |
31 | 1272717231.07 98 FF |
32 | 1272717234.38 98 FF |
33 | 1272717236.12 18 FF |
34 | 1272717241.48 98 FF |
35 | 1272717244.45 98 FF |
36 | 1272717247.05 98 FF |
37 | 1272717249.65 98 FF |
38 | 1272717252.25 98 FF |
39 | 1272717254.53 98 FF |
40 | 1272717255.3 98 FF |
41 | 1272717255.66 98 FF |
42 | 1272717257.9 98 FF |
43 | 1272717260.5 98 FF |
44 | 1272717263.1 98 FF |
45 | 1272717264.88 98 FF |
46 | 1272717266.18 98 FF |
47 | 1272717268.79 98 FF |
48 | 1272717271.39 98 FF |
49 | 1272717274.69 98 FF |
50 | 1272717275.99 98 FF |
51 | 1272717276.76 98 FF |
52 | 1272717278.79 88 FF |
53 | 1272717279.19 98 FF |
54 | 1272717279.89 98 FF |
Hallo Rudi, das habe ich ja nicht ausgeschlossen.. Ich habe nur gesagt dass genau die 98 FF aus dem Log vermutlich ein übertragungfehler ist. Vielleicht kommen ja gerade immer nur diese Adressen zustande bei Übertragungsfehlern. Vielleicht sollte ich auch mal auf meinem Bus genauer mitloggen. Bei Dir ist das ja ziemlich oft, oder? Sind das Sekunden? oder was ist das für eine Zeiteinheit? Gruß Ingo
> Vielleicht sollte ich auch mal auf meinem Bus genauer mitloggen. > Bei Dir ist das ja ziemlich oft, oder? Sind das Sekunden? oder was ist > das für eine Zeiteinheit? Ja, sind Sekunden. Die Daten kommen kontinuierlich, aber nicht zyklisch.
Angehängte Dateien:
-
ems_0001.png
390 KB -
ems_0002.png
370 KB -
ems_0003.png
510 KB -
ems_0004.png
440 KB -
ems_0005.png
510 KB -
ems_0006.png
500 KB -
ems_0007.png
520 KB -
ems_0008.png
520 KB
Anbei mal ein paar Oszi Screens von den Nachrichten und dann noch die Reaktion wenn ich auf einen Request antworte.
Hallo Rudi, in Bild 4 und 5 scheint das wohl keine Störung zu sein. Das scheint wohl die RC30 zu sein (0x10). Die kleinen "Störungen" sehen genauso aus wie das nachfolgende Byte. Also ob die RC30 die Bytes erst zum Sendeteil überträgt und trotzdem den Weg auf den Bus finden. Und dann wird erst das Byte übertragen. Beim lesen dürfte das Problem vermutlich nicht auftreten. Die anderen Busteilnehmer scheinen ja nicht so eine Pause zu machen. In Bild 1 bist Du vermutlich in der Zeile verrutscht. Das sind 1,04 ms = 961,5 Hz also 10 Bit. die letzten beiden Bilder sind vermutlich Deine Antwort, oder? Sieht so aus als ob es da wirklich eine Kollision gibt. Kann das sein dass Du zu langsam geantwortet hast und das nächste Telegramm oder eine Fehlermeldung verschickt wird? Gruß Ingo
> in Bild 4 und 5 scheint das wohl keine Störung zu sein. > Das scheint wohl die RC30 zu sein (0x10). Die kleinen "Störungen" sehen > genauso aus wie das nachfolgende Byte. Also ob die RC30 die Bytes erst > zum Sendeteil überträgt und trotzdem den Weg auf den Bus finden. Und > dann wird erst das Byte übertragen. Beim lesen dürfte das Problem > vermutlich nicht auftreten. Die anderen Busteilnehmer scheinen ja nicht > so eine Pause zu machen. Das sehe ich jetzt auch. Mhh, sehr merkwürdig. > In Bild 1 bist Du vermutlich in der Zeile verrutscht. Das sind 1,04 ms = > 961,5 Hz also 10 Bit. Das ist das Byte mit dem Low Stopbit (Break). > die letzten beiden Bilder sind vermutlich Deine Antwort, oder? Ja, genau. > Sieht so aus als ob es da wirklich eine Kollision gibt. Kann das sein dass > Du zu langsam geantwortet hast und das nächste Telegramm oder eine > Fehlermeldung verschickt wird? Nein, eigentlich nicht. Die ersten beiden Bytes sind der Request und kurz danach der Response mit "Fehler". Eigentlich wird ein normaler Response etwas später verschickt. Das habe ich auch probiert, aber ohne ersichtliche Besserung. Den einzigen Fehler den ich noch sehe ist das falsche Timing nach dem zweiten FET und der Diode in meiner Sendeschaltung. Beim abschalten (Low/High-Flanke auf dem Bus) floated der Drain-Ausgang und Diodeneingang. Bei dir wäre das zwischen Transistor und Diode. Da müsste man einen Pullup dran hängen der durch eine Diode + C die Strecke auf einen definierten Pegel zieht, wenn der FET abgeschaltet wird. Das C wird über den Bus geladen und sollte dann bei etwa 15V hängen. Denkst du das würde funktionieren ?
Rudi schrieb: > ein, eigentlich nicht. Die ersten beiden Bytes sind der Request und > kurz danach der Response mit "Fehler". Achso, jetzt sehe ich das erst. Also das Polling dann eine kurze Pause, Deine Antwort, dann eine Pause Dein Break. Sieht so aus als ob kurz nach Deinem Break ein Break vom Busmaster kommt, oder?Deine Sendeschaltung zieht den Signalpegel ja etwas tiefer als in dem Polling vom Master. Das letzte Break scheint den selben Low-Pegel zu haben wie das Polling. Der Master wartet ja kaum und schießt sofort nach Deinem 0-Stopbit sofort los. Was Du jetzt mit dem Floaten meinst verstehe ich jetzt nicht so ganz Sieht doch ganz gut aus. Oder meinst Du dass das zweite Break dadurch entsteht? Gruß Ingo
Die Low/High-Flanke kommt zu spät, braucht zu lange. D.h. die "High"-Bits sind etwas kürzer und die "Low"-Bits länger.
Angehängte Dateien:
-
ems_0009.png
520 KB -
ems_0010.png
530 KB -
ems_0011.png
480 KB
Vergiss es ;-) Das Problem hatte ich im Testaufbau gesehen, auf dem Bus sieht es besser aus. Anbei noch 3 Bilder von meinem Response und die Variationen. Sieht mir irgendwie nach einem Timing-Problem aus. Ab und sieht es auch so aus wie es soll. Oben der Bus und unten der TX-Ausgang vom uC.
Angehängte Dateien:
-
RC30.png
510 KB
Wenn man jetzt Bild 04 und 10 miteinander vergleicht würde mir jetzt Spontan einfallen das die RC30 nur mit 0,5Vss sendet und der Busmaster das Signal aufarbeitet und für alle anderen Busteilnehmer aufarbeitet. Bei beiden Signalen fällt mir auf dass die Daten doppelt vorhanden sind und das Low-Level bei dem Echo anders ist. Also nur durch ein floaten am FET kann ich mir sowas nicht vorstellen. Habe bei meiner RC 30 mal die Platine von beiden Seiten fotografiert und keinen Hinweis dafür gefunden dass dort irgeinde Schaltung zu finden ist wie in unserem Sendeteil. Dort wurde nur irgendwie ein CMOS-Logik-Baustein verwendet. Die Schaltung habe ich aber ignoriert weil ich die nicht so ganz verstanden habe und nicht sicher war dass ich die richtig entflechtet hatte. Mein Ergebnis hänge ich mal an. Aber warum sollte es dann eine Prüfsumme geben wenn der Busmaster sowieso alles widerholt. Dann könnte die RC30 doch einfach überprüfen ob das Echo korrekt ist. Aber das würden die anderen Busteilnehmer ja nicht mitbekommen wenn die RC30 feststellt dass das Echo falsch war. Und müsste sich dann melden dass das letzte Telgramm fehlerhaft wäre.. Keine Ahnung.... Ist das denn bei allen anderen Busteilnehmer auch so, und nur bei Telegrammen vom Busmaster ohne Echo? Gruß Ingo
> Wenn man jetzt Bild 04 und 10 miteinander vergleicht würde mir jetzt > Spontan einfallen das die RC30 nur mit 0,5Vss sendet und der Busmaster > das Signal aufarbeitet und für alle anderen Busteilnehmer aufarbeitet. Das glaube ich nicht. Der Bus wird aufbereitet hört sich komisch an. Wir sind ja nicht an der RC30 sondern an der ???BCXX??? am Klinkenstecker. Die Schaltung wird dort sicherlich ganz anders sein als bei den internen Busteilnehmern. Ich werde die mal zerlegen und Bilder machen. > Bei beiden Signalen fällt mir auf dass die Daten doppelt vorhanden sind > und das Low-Level bei dem Echo anders ist. Die doppelten Signale kann ich auch nicht erklären. Das Low-Level liegt an der verwendeten Diode in der Sendeschaltung. > ... > CMOS-Logik-Baustein verwendet. Die Schaltung habe ich aber ignoriert > weil ich die nicht so ganz verstanden habe und nicht sicher war dass ich > die richtig entflechtet hatte. Mein Ergebnis hänge ich mal an. Ja, das ist ein Busteilnehmer und kein externes etwas mit einer 3m Antenne ;-) > Aber warum sollte es dann eine Prüfsumme geben wenn der Busmaster > sowieso alles widerholt. Dann könnte die RC30 doch einfach überprüfen ob > das Echo korrekt ist. Aber das würden die anderen Busteilnehmer ja nicht > mitbekommen wenn die RC30 feststellt dass das Echo falsch war. Und > müsste sich dann melden dass das letzte Telgramm fehlerhaft wäre.. Nein, die Prüfsumme ist für den Empfänger und ob der sich bei fehlerhafter Prüfsumme meldet ist eine andere Geschichte. Da kommt es drauf an ob er die Daten haben wollte/braucht oder ob es später auch okay ist (Timeout). > Ist das denn bei allen anderen Busteilnehmer auch so, und nur bei > Telegrammen vom Busmaster ohne Echo? Ich habe bei einem Teilnehmer noch einen ripple gesehen, ich denke da ist die Verdrahtung oder der Sendeteil etwas daneben. Ich werde da nochmal messen und Knipsen.
Zu der Schaltung: Tx geht über ein (R)C-Filter an den Inverter (Treiber) und dann wird nur der Analoganteil ... Wohin gespeist ? Der muss doch wieder an den Bus ? Rx geht an den Treiber, Diode, R-Filter und dann Pullup damit es nach der Diode nicht floated, und dann den Doppelinverter und den RC-Filter, der ist bei der Übertragungsrate okay. Der RX und Tx-Pfad sollten noch direkt an den Bus gehen oder sehe ich das nicht ???
Rudi schrieb: > Der RX und Tx-Pfad sollten noch direkt an den Bus gehen oder sehe ich > das nicht ??? Ja, aber ich habe nirgendwo etwas finden können wo es zum Bus geht. Habe mich aber auch nicht getraut das LCD-Display von der Platine zu nehmen. Habe das vor Tausend Jahren auch schon mal bei einer alten Uhr probiert und hatte dannach nur Kontaktschwierigkeiten. Rudi schrieb: > Die doppelten Signale kann ich auch nicht erklären. Das Low-Level liegt > an der verwendeten Diode in der Sendeschaltung. Ist schon klar. Aber bei Bild 4 kann man sehen dass der Signal-Low-Pegel vom Polling und dem Echo etwa gleich sind und Das Low-Level von Deinen gesendeten Daten etwas niedriger liegt. Halte es auch für unwahrscheinlich dass das Echo irgendwie von Deiner Schaltung erzeugt wird. Irgendeiner schickt das Echo. Keine Ahnung wie und warum. Und dass die RC30 die Signale vorher auf den Bus intern vor dem Senden irgendo herumschiebt und die dabei ungewollt auf den Bus kommen kann ich mir eigentlich auch nicht vorstellen. Man könnte ja mal zum Spass ausprobieren was passiert wenn man auch nur ein Signal mit 0,5Vss auf den Bus sendet. Wenn das bei der RC30 entsteht dürfte sich ja dann am Bus nichts ändern. Aber ehrlich gesagt kann ich mir auch nicht vorstellen dass nur mit einem so "schwachen" Signal gesendet wird. Rudi schrieb: > Wohin gespeist ? Der muss doch wieder an den Bus ? Ich habe nirgendwo einen Hinweis gefunden. Habe allerdings auch keine Ahnung wo der R17 hingeht. Der Pfeil nach oben soll keine Versorgungsspannung sein. Sind alles nur Vermutungen habe keine Ahnung was da so auf dem Bus abgeht .... Gruß Ingo
Danke noch mal dafür dass Du den letzten Rest der CRC herausgefunden hast. Ich glaub ich wäre da nie hinter gekommen. Bei mir funktioniert die CRC-Prüfung jetzt auch einwandfrei. Die Festplatte war übrigens nicht das Problem. MySQL hat mit anwachsen der Datenmenge immer mehr Speicher benötigt , bis hinterher die Auslastung permanent bei 100% lag. Hatte das schon eher auf mein Java-Programm bezogen. Bei 40MByte Daten war ein Arbeiten nicht mehr möglich. Habe bei MySQL allerdings auch die InnoDB und nicht myISAM genommen. Angeblich sollte InnoDB ja für viele Schreibzugriffe und wenig Lesezugriffe ausgelegt sein. Wieso hats Du denn die MyISAM genommen? Deine Datenbank müste ja inzwischen ein vielfaches meiner Datenbank haben. Was für eine Prozessorlast verursacht denn Deine MySQL? Und was hast Du für einen Rechner, Bei mir ist es nur ein IBMT43 Pentium M 750 1,86 GHz und 1,5GB RAM und habe bei 40 MByte schon eine Auslastung von permanent 100%. Nach löschen der ganzen Daten war ich wieder bei 10% Auslastung und weniger
Angehängte Dateien:
> Deine Datenbank müste ja inzwischen ein vielfaches meiner Datenbank > haben. Was für eine Prozessorlast verursacht denn Deine MySQL? Und was > hast Du für einen Rechner, Ich habe einen AMD Athlon(tm) XP 1800+ und 500MB Ram. Die CPU-Last liegt bei etwa 25% im Durchschnitt. Es ist aber nur der Server der die Daten in die DB schreibt und die Bilder generiert (siehe Anhang). Ich speicher und generiere z.Z. für zwei Heizungen. Für die eine habe ich etwa 400MB Daten und 400MB Index (12Mill. Einträge) und für die andere etwa 300MB Daten und 300MB Index (9 Mil.Einträge) ;-) Ich will das ganze aber noch optimieren da die Abfrage und das Einfügen zu lange dauert. Wie Speicherst du die Daten, geparst, nur was du brauchst oder als blob ? Ich speicher jede Temperatur usw. einzeln als Wert mit Datum, Sender und Typ.
Ich habe die CRC-Berechnung noch etwas 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]) |
Noch etwas zur Datenbank. Für diesen Fall der "Datensicherung" ist die myISAM einfach besser und schneller. Die Features der InnoDB braucht man dabei einfach nicht. Ich werde das Format soweit aufbrechen, das jeder Datentyp eine eigene Tabelle bekommt. Das sollte die Abfragen zum Teil recht gut beschleunigen und evtl. funktioniert das dann auch über Ajax in Realtime ... Hast du dir schon etwas für den "späteren" nicht Frickelaufbau überlegt ?
Angehängte Dateien:
-
MySQL.png
3,1 KB
Also bei Rudi schrieb: > Für diesen Fall der "Datensicherung" ist die > myISAM einfach besser und schneller. Habe ich auch festgestellt.. Satt permanent 100% und Absturz nach 2,5 Stunden habe ich jetzt nur noch durchschnittlich 80%. Das ändern der Datenbankengine ging mit nur zwei Mausklicks. Rudi schrieb: > Ich werde das Format soweit aufbrechen, das jeder Datentyp eine eigene > Tabelle bekommt. Vielleicht ist das Problem dass ich zur Zeit noch keine Datenreduzierung mache und alle Werte eines Telegramms abspeichere. Vielleicht sollte ich das auch so wie Du handhaben und nur Tabellen nach Datentyp oder nur eine einzige Tabelle mit allen Werten nehmen. Dadurch bräuchte ich viele doppelte Werte nicht speichern... Vielleicht hilfts. Bei Der CRC Berechung musste ich nur noch das XOR mit 0x0C einfügen. Schätze mal dass sie einer Deiner beiden Berechnungen sehr ähnlich ist. Habe meine Schwirigkeiten mit unbekannten Programmiersprachen ;-) Mit der korrekten Prüfsumme kann man auch schnell sehen wieviele Telegramme fehlerhaft sind. Bei mir an einem Tag teilweise bis zu 200. Das kann aber auch an der Prozessorauslastung liegen. Als Endgültige Version hätte ich schon gerne eine vernünftig geätzte Platine mit Gehäuse. Eventuell sogar genau für die freien Steckplätze in der Heizung. Vielleicht auch mit dem XPORT. Damit der "Server" nicht neben dem Wandler stehen muss. Vielleicht könnte man ja auch zusammen die Platine entwickeln wenn wir uns auf eine Hardware und Sendeschaltung einigen könnten. Gruß Ingo
Achso... habe noch mal in Deiner WAV-Datei gesucht und soweit festgestellt dass alle Busteilnehmer außer der Master selber immer nach einem gesendeten Byte ein Byte Pause machen und manchmal das Telegramm nach noch längerer Pause (etwa 15ms) weiter fortzusetzen. Der Busmaster pustet seine Telegramme einfach ohne Wartezeiten raus. Entweder kann die Sendestufe das nicht anders machen oder der Busmaster oder irgendjemand anders sendet manchmal ein Echo. Gegen das Echo spricht nur dass die Störungen vorher kommen.
> Habe ich auch festgestellt.. Satt permanent 100% und Absturz nach 2,5 > Stunden habe ich jetzt nur noch durchschnittlich 80%. Das ändern der > Datenbankengine ging mit nur zwei Mausklicks. Anbei meine Mysql Speicher-Konfiguration, evtl. bringt es noch etwas Besserung.
1 | [mysqld] |
2 | key_buffer = 32M |
3 | max_allowed_packet = 2M |
4 | table_cache = 64 |
5 | sort_buffer_size = 10M |
6 | net_buffer_length = 1024K |
7 | read_buffer_size = 5M |
8 | read_rnd_buffer_size = 10M |
9 | myisam_sort_buffer_size = 8M |
10 | |
11 | [isamchk] |
12 | key_buffer = 20M |
13 | sort_buffer_size = 20M |
14 | read_buffer = 2M |
15 | write_buffer = 2M |
16 | |
17 | [myisamchk] |
18 | key_buffer = 40M |
19 | sort_buffer_size = 40M |
20 | read_buffer = 5M |
21 | write_buffer = 5M |
> Als Endgültige Version hätte ich schon gerne eine vernünftig geätzte > Platine mit Gehäuse. Ich auch ;-). Was hältst du von einem Hutschienengehäuse (eine Einheit) ? Da würden oben und unten etwa jeweils 5-6 Kontakte Platz haben. > Eventuell sogar genau für die freien Steckplätze in > der Heizung. Vielleicht auch mit dem XPORT. Damit der "Server" nicht > neben dem Wandler stehen muss. Vielleicht könnte man ja auch zusammen > die Platine entwickeln wenn wir uns auf eine Hardware und Sendeschaltung > einigen könnten. Wie breit ist der XPORT ? Dadurch das der nur eine Steckerleiste hat wird das etwas wackelig. Kann der POE ? Die Stromversorgung braucht man dann ja auch noch. Für die Platine dachte ich mir einen Mega der mir den EMS-Bus auf CAN umsetzt. Alles Mehrarbeit, aber ich will noch ein paar andere Sachen steuern und für einen Bus habe ich nichts besseres gefunden. Ich denke man könnte die Platine zweigleisig fahren. Einmal normales CAN Interface mit normalen Steckverbindern und dann einen Platz für den XPORT, geht der an die UART ? Das könnte funktionieren.
Hallo Rudi, Hallo Ingo, wollte meine Stand sagen bzgl. der Telegramme UBA3. Mein NetIO hat beim Empfang der UBA3 Telegramme Zeichen verloren. Somit ist auch bei mir das Protokoll gleich. Die Checksummenberechnung habe ich auch gleich getestet -funktioniert echt Klasse. Gruss Matthias
Hurra! habe doch tatsächlich den Fehler gefunden. Meine Logger läuft jetzt mit vielleicht 10% Prozessorleistung und der Systemtakt ist auf 40% reduziert.. Also statt 40Watt braucht das Notebook jetzt auch nur noch geschätze 15 Watt. Das Problem lag nicht an MySQL, sondern an meiner Programmversion hatte irgendwo eine Zeile von einem Test nicht rausgenommen. Es wurden also jeder decodierte und in MySQL abgespeicherter Wert nochmals ausgelesen, decodiert und außerhalb von MySQL mitgeloggt. Werde jetzt auch noch mal die Daten reduzieren und vermutlich auch alles in einer Tabelle nach Datentyp abspeichern um doppelte Werte nicht mitloggen zu müssen. Bei mir wurden bisher alle Werte die decodiert werden konnten pro Telegramm komplett in MySQL mitgeloggt. Rudi schrieb: > Ich auch ;-). Was hältst du von einem Hutschienengehäuse (eine Einheit) > ? Da würden oben und unten etwa jeweils 5-6 Kontakte Platz haben. Na eigentlich doch eine gute Idee.. hoffe Du meinst ein Geäuse mit etwa FI-Breite und nicht einer LS-Breite. Dann könnte man eine Busplatine machen mit Steckplätzen und den Kontaktklemmen und wenn es passt noch den ATMegaXY mit dem EMS-Bus-Teil. ALs Steckplatz senkrecht könnte man dann die Plantine mit dem XPORT machen und kann von oben die Ethernet-Buchse als Durchbruch ausführen. Oder eine CAN-Platine, oder ...... Vielleicht auch nur eine Platine die man mit XPORT oder MAX232 oder CAN-Controller bestückt werden kann. Der XPort ist eigentlich nicht viel größer als so RJ-45-Buchse mit Transceiver. Müsste eigentlich ziemlich stabil sein wenn man den auf der Platine auflötet. Habe noch nie einen gehabt. Der XPort wird eigentlich direkt an an die Pinn des Atmega gehangen und läuft mit 3,3 Volt. Soll aber 5Volt tolerant sein. Vielleicht gibt es ja auch eine 5Volt-Version. Mit welcher Spannung wolltest Du den die Platine versorgen? bei 3,3 Volt könnte man SD/MMC-Karten direkt ohne irgendwelche Pegelwandlung an den ATmega hängen, genauso wie den XPort. Rudi schrieb: > Mega der mir den EMS-Bus auf CAN > umsetzt. Alles Mehrarbeit, aber ... Habe auch noch ein paar Sachen für die ich einen eigenen Hausbus gebrauchen könnte. Bin da bisher auch bei CAN hängen geblieben. Aber bisher noch nicht weiterverfolgt.. Gruß Ingo
> Na eigentlich doch eine gute Idee.. hoffe Du meinst ein Geäuse mit etwa > FI-Breite und nicht einer LS-Breite. Was ist LS ??? Die Platine würde in einer Einheit 86.5x14 sein. Hier mal ein Beispiel von einem Sklaven in 2 Einheiten: http://www.mikrocontroller.net/attachment/77294/can_ssr_b.png http://www.mikrocontroller.net/attachment/77294/can_ssr_t.png Die Bestückung ist in etwa 14mm Breit. Bei 2 Einheiten sind die Platinen 33mm Breit. Das wird/ist übrigens ein SSR mit CAN-Bus-Interface, z.Z. mit Mega8 und externem EEProm und SRAM. Ich werde wohl auf den 328 wechseln, der M8 hat mir etwas zu wenig Speicher. > Mit welcher Spannung wolltest Du den die Platine versorgen? bei 3,3 Volt > könnte man SD/MMC-Karten direkt ohne irgendwelche Pegelwandlung an den > ATmega hängen, genauso wie den XPort. Mit 3V3, für 5V bekommt man kaum noch billige Periphery-Ics. > Dann könnte man eine Busplatine machen mit Steckplätzen und den > Kontaktklemmen und wenn es passt noch den ATMegaXY mit dem EMS-Bus-Teil. > ALs Steckplatz senkrecht könnte man dann die Plantine mit dem XPORT > machen und kann von oben die Ethernet-Buchse als Durchbruch ausführen. > Oder eine CAN-Platine, oder ...... Die senkrechte Installation ist etwas heikel, ordentliche Steckverbinder mit Verschraubung nehmen schon fast die komplette Platine ein. Naja, mal schauen. Ich werde jedenfalls nicht direkt über Netz gehen, sondern über CAN an einen Master der dann die SD-Karte hat und Netzwerk unterstützt.
Rudi schrieb: > Was ist LS ??? Leitungsschutzschalter (Sicherung) Aber ist wohl die Größe die Du meintest.. Rudi schrieb: > Mit 3V3, schön... Rudi schrieb: > SSR Ist das jetzt die LS-Rache ;-) Watt isn datt? Secondary Surveillance Radar (Sekundärradar) wird es wohl nicht sein.. Schätze mal SolidStateRelais? Klingt interessant... Rudi schrieb: > Naja, mal schauen. Ich werde jedenfalls nicht direkt über Netz gehen, > sondern über CAN an einen Master der dann die SD-Karte hat und Netzwerk > unterstützt. Also so eine SD-Karte als Option fände ich schon ganz gut. Muss mann ja nicht bestücken. Wenn mann noch einen Master mit ins Gehäuse stecken könnte ware das auch ganz gut. Also dann wäre eine Steckplatzversion schon ganz OK. Rudi schrieb: > Die senkrechte Installation ist etwas heikel, ordentliche Steckverbinder > mit Verschraubung nehmen schon fast die komplette Platine ein. Hat das Gehäuse denn keine Führungsnut oder ähnliches? Und wenn man so flexible Leiterplattenverbinder nehmen würde? Ist jau auch auf der SSR-Platine oder? Gruß Ingo
> Ist das jetzt die LS-Rache ;-) Nein ;-) > Watt isn datt? Secondary Surveillance Radar (Sekundärradar) wird es wohl > nicht sein.. Schätze mal SolidStateRelais? Klingt interessant... Solid State Relais, ja. > Also so eine SD-Karte als Option fände ich schon ganz gut. Muss mann ja > nicht bestücken. Wenn mann noch einen Master mit ins Gehäuse stecken > könnte ware das auch ganz gut. Also dann wäre eine Steckplatzversion > schon ganz OK. Auf 86.5x14 ist nicht wirklich viel Platz. Ein SD-Karten-Slot mit Karte hat etwa 17x15mm, also nicht geeignet. Mehr Speicher/Flash ist eigentlich kein Problem, wenn es nicht grad Gigabyte sein müssen. > Hat das Gehäuse denn keine Führungsnut oder ähnliches? Und wenn man so > flexible Leiterplattenverbinder nehmen würde? Ist jau auch auf der > SSR-Platine oder? Der Verbinder ist für die Programmierung der CPU. Schau dir mal die Gehäuse für Hutschiene an, dort kann man mehrere Platinen unterbringen, z.B. die von axxatronic, die cnmb Serie.
Angehängte Dateien:
-
xport.gif
7,4 KB
IngoF schrieb: > Der XPort ist eigentlich nicht viel größer als so RJ-45-Buchse mit > Transceiver. Müsste eigentlich ziemlich stabil sein wenn man den auf der > Platine auflötet. Habe noch nie einen gehabt. Ja, der XPORT sitzt bombenfest (hat zusätzlich zu den Pins auch noch 2 Lötfahnen an der Seite und 2 Kunststoffböbbel. Abmessungen wie eine standard RJ45 Buchse mit LEDs, nur die Länge ist anders: ca 35mm > Der XPort wird eigentlich direkt an an die Pinn des Atmega gehangen und > läuft mit 3,3 Volt. Soll aber 5Volt tolerant sein. Vielleicht gibt es ja > auch eine 5Volt-Version. Ja, so ist es: Versorgung 3.3V Datenleitungen 3.3V, 5V tolerant. Stromaufnahme ist im Datenblatt leider nicht aufgeführt, habe aber mal interessehalber gemessen: irgendwas zwischen 30 und 70 mA. variiert halt je nachdem ob er daten uebertraegt, wie die leds leuchten etc. Gruss, Malte
Das XPort-Gehäuse ist 18.25mm breit, würde also nicht in das Hutschienengehäuse passen.
Stimmt.. die Breite ist 18,25. Aber die Höhe ist inkl. Anschlüsse 16,75mm müsste also so gerade reinpassen inkl. Platine und Anschlüsse. Hängt natürlich von der Wandstärke ab ob man 16,75mm innen hat. Man kann ihn ja hochkant einbauen... Oder habe ich da noch irgendwas übersehen? Gruß Ingo
> Man kann ihn ja hochkant einbauen... Oder habe ich da noch irgendwas > übersehen? Ja, das Hutschienengehäuse ist 14mm breit.
Hi, ich hoffe das schweift jetzt nicht zu sehr vom Thema ab, hat aber schon etwas hiermit direkt zu tun: In der Zwischenzeit sind mir noch ein paar zusätzliche Ideen gekommen, so dass ich ausser des (noch ausstehenden) KM271 Nachbaus drei weitere Meßstellen haben werde: Wärmezähler+Wasserzähler Impulsmessung und mehrere SO-Hutschienenzähler für Energieverbrauch. Die Stellen (Heizung, Wasserzähler, Zählerschrank) sind ca 4-10m voneinander entfernt. Im Prinzip will ich ja immer noch per Ethernet an die Messdaten ran, will aber aus Kostengründen nicht an jede Einheit nen XPORT bauen. Was haltet ihr generell von der Idee, dass ich an die AVRs TTL->RS485 Interfaces hänge und alle mittels RS485 Bus vernetze? Am Server, der sowieso 24/7 läuft würde dann ein RS485->USB Wandler hängen. Gesamtlänge des Busses wären geschätzt etwa 100m. Hat da jemand bedenken? Habe bisher noch nichts mit RS485 gemacht, aber wenn ihr sagt das wäre kein Problem, würde ich es gerne so realisieren. Das KM271 Board wird es dann mit 2 Schnittstellen geben (RS232 / 485). Hatte nochmal einen Test mit dem XPORT direkt gemacht, aber jedes Mal wenn ich den im Logamatic slot betreibe spinnen mir die analogpegel rum. MAX232 macht hingegen keine Probleme. Scheint wohl an den höheren Strömen zu liegen?? Gruss, Malte
Also habe diese Schnittstelle noch nie benutzt. Hab da mal was gefunden://www.itwissen.info/definition/lexikon/RS-485-RS-485. Gruß Ingo
@Malte Bayer > Hat da jemand bedenken? Habe bisher noch nichts mit RS485 gemacht, aber > wenn ihr sagt das wäre kein Problem, würde ich es gerne so realisieren. Das funktioniert, der Programmieraufwand ist aber nicht ohne für ein funktionierendes Multisensor-System. Die RS485 ist zwar in Hardware leicht zu realisieren, dafür steckt der Aufwand in der Software. Man muss sich auch vorher überlegen ob man den Bus in Full- oder Half-Duplex baut, da davon direkt die Software betroffen ist. Ich wollte den Bus auch benutzen, aber der Softwareaufwand für OSI Layer2-Layer4 ist mir zu hoch bzw. muss man diese Layer in Software realisieren (http://de.wikipedia.org/wiki/OSI-Modell). > Das KM271 Board wird es dann mit 2 Schnittstellen geben (RS232 / 485). > Hatte nochmal einen Test mit dem XPORT direkt gemacht, aber jedes Mal > wenn ich den im Logamatic slot betreibe spinnen mir die analogpegel rum. > MAX232 macht hingegen keine Probleme. Scheint wohl an den höheren > Strömen zu liegen?? Wie sieht denn deine bisherige Schaltung aus ?
Rudi schrieb: > Ich habe die CRC-Berechnung noch etwas vereinfacht: > for i in range(0,len(a)-1): > d = 0 > if crc1 & 0x80: > crc1^=12 > d = 1 > crc1 = crc1 << 1 > crc1 &= 0xfe > crc1 |= d > crc1 = crc1^int(a[i]) @Rudi dass wäre ja super, wenn die CRC-Berechnung damit geht. Ich habe Deine Lösung mal in Delphi übersetzt, komme aber nicht zu den richtigen Ergebnissen. Siehst Du den Fehler? Danke, Mario function Berechne_Checksumme(data: array of integer; TelLaenge:integer ): Integer; var crc1, crc2 : integer; i, d : Integer; begin crc1 := 0; for i:=0 to TelLaenge-4 do begin d := 0; if crc1 AND $80 = 1 then begin crc1 := crc1 XOR 12; d := 1; end; crc1 := crc1 SHL 1; //linksschieben crc1 := crc1 AND $fe; crc1 := crc1 OR d; crc1 := crc1 XOR ord(data[i]); end; result := crc1; end;
Mario schrieb: > for i:=0 to TelLaenge-4 do Warum denn dass? Der Quelltext sieht eigentlich ganzgut (seoweit ich mich noch an Delphi erinnere) Aber warum Telegrammlänge -4 sind das die Rahmenbytes AA und 55? Dann müsste die Schleife doch von 2 bis -2 gehen.. Also bei mir hat es funtkioniert.. Schätzte mal mein JAVA-Quelltext hilft Dir auch nicht weiter ;-) Gruß Ingo
@IngoF die Rahmenbytes sind entfernt, nur das Byte für die Telegrammlänge hängt noch an. Deshalb werden die letzten 3 Byte nicht in der CRC-Summe berechnet. Letztes Byte = Telegrammlänge Vorletztes Byte = CRC HighByte Vorvorletztes Byte = CRC LowByte Berechnet werden soll ja der CRC von empfangenen Telegrammen, dann wird mit dem Berechneten verglichen. Bei manchen Telegrammen stimmt die errechnete CRC ja auch z.B. data[0] := $08; data[1] := $10; data[2] := $14; data[3] := $00; data[4] := $0D; data[5] := $D2; data[6] := $F9; data[7] := $29; //Checksumme LowByte data[8] := $00; //Checksumme HighByte data[9] := $09; //Telegrammlänge TelZeiger := 10; Bei anderen kommt 0000 raus z.B. bei data[0] := $08; data[1] := $00; data[2] := $07; data[3] := $00; data[4] := $03; data[5] := $03; data[6] := $00; data[7] := $02; data[8] := $00; data[9] := $00; data[10] := $00; data[11] := $00; data[12] := $00; data[13] := $00; data[14] := $00; data[15] := $00; data[16] := $00; data[17] := $37; data[18] := $00; //Checksumme LowByte data[19] := $13; //Checksumme HighByte TelZeiger := 20; //Telegrammlänge Rudi schrieb doch, dass die Berechnung mit allen Telegrammen passen sollte. Irgendwelche Ideen? Meine Heizungsüberwachung läuft übrigens seit November 2009 als Delphi-Anwendung recht stabil. Die SQL-Datenbank hat schon 650.000 Einträge, dass sind ca. 51 MByte. Die Auswertung und Anzeige erfolgt im Browser per PHP. Nur mal so, als positives Feedback. bye, Mario
> Bei manchen Telegrammen stimmt die errechnete CRC ja auch z.B. > data[0] := $08; > data[1] := $10; > data[2] := $14; > data[3] := $00; > data[4] := $0D; > data[5] := $D2; > data[6] := $F9; > data[7] := $29; //Checksumme LowByte > data[8] := $00; //Checksumme HighByte > data[9] := $09; //Telegrammlänge > TelZeiger := 10; Da ist auch die 0x00 am Ende. Das ist das serielle Break-Zeichen und geht nicht in die CRC-Berechnung mit ein, noch ist es Teil der CRC. Also die Daten: 0x08 0x10 0x14 0x00 0x0d 0xd2 0xf9 die CRC 0x29 Bei deinem zweiten Bsp. stimmt etwas nicht. Die 0x13 gehört da nicht hin. Bei diesem Bsp. sollte die CRC 0x37 sein, ich habe es jetzt nicht nachgerechnet.
Mario schrieb: > if crc1 AND $80 = 1 then Ganz übersehen. Eigentlich kann die Bedingung nie wahr sein... Denke das sollte laufen: if crc1 AND $80 = $80 then
IngoF schrieb: >> if crc1 AND $80 = 1 then > > Ganz übersehen. Eigentlich kann die Bedingung nie wahr sein... Denke das > sollte laufen: > > if crc1 AND $80 = $80 then Danke, danke, manchmal sieht man den Wald vor lauter Bäumen nicht. Das war die Lösung, der Rest hat gepasst. Hier nochmal meine Funktion mit der eingebauten Änderung, falls es jemand braucht: function Berechne_Checksumme(data: array of integer; TelLaenge:integer ): Integer; var crc1 : integer; i, d : Integer; begin crc1 := 0; for i:=0 to TelLaenge-4 do begin d := 0; if crc1 AND $80 = $80 then begin crc1 := crc1 XOR 12; d := 1; end; crc1 := crc1 SHL 1; //linksschieben crc1 := crc1 AND $fe; crc1 := crc1 OR d; crc1 := crc1 XOR ord(data[i]); end; result := crc1; end; Nochmals danke, Mario
@Rudi: siehe http://wiki.neo-soft.org/index.php/Bild:Km271_schematic.gif An Pin 12 habe ich uebrigens keine -24V sondern auch ein GND. So sieht die Schaltung auf der Platine aus, funktioniert soweit ich das beurteilen kann. meine Pins 11+12 habe ich nicht verwendet, also ist der komplette ground der Platine an Pin 1 angeschlossen (viel massefläche, aber das scheint nicht das problem zu sein. IN vom 3.3Vreg hängt direkt an +5V, der Ausgang gegen Masse mit 2 Kondensatoren (100n kerko und 10uf elko), danach gehts gleich zum xport, dessen masse natuerlich auch mit K4/Pin1 verbunden ist. Wenn ich nun den spannungsregler für den xport einsetze und diesen somit mit dem rest vom KM271 verbinde, bekomme ich bei ALLEN temperaturen falsche Werte (oft mit 12° Abweichung). Zieht der Xport möglicherweise zuviel Strom von der 5v leitung? Gruss, Malte
@Malte Bayer
Danke !
> Zieht der Xport möglicherweise zuviel Strom von der 5v leitung?
Das kann sein. Hast du mal den Strom gemessen ? Netzwerk sollte etwa
100mA ziehen, evtl. auch mehr. Bricht die Spannung zusammen oder kann
dein LDO evtl. zu wenig Strom liefern ?
Hast du das Problem mit den Temperaturen auch ohne Netzwerkkabel ?
Reinhard schrieb: > Hallo, > ich habe in Verbindung mit einem Buderus Service Key versucht meine > Heizung (GB-125) abzufragen. Hallo falls Reinhard oder ein anderer Buderus-Service-Key Besitzer hier mitliest bitte mal melden. Würde mir den gerne mal für ein paar Tage ausleihen. DANKE Gruß Ingo
Hi Rudi, Habe an einem anderen Projekt mal den Strom vom xport gemessen, der zieht an 5V (also vor dem 3.3v reg) ca 70-110mA je nach Laune (idle vs Datenübertragung). Ob die 5V Seite in der Logamatic zusammenbricht habe ich leider verpasst zu messen, am regler liegts aber nicht, der ist überdimensioniert die 1A Version. Die Temperaturprobleme kommen sobald ich den Spannungsregler einstöpsle und somit den xport mit dem Rest verbinde, egal ob Netzwerkkabel angeschlossen ist oder nicht. Hatte ich zuerst auch gedacht wegen Ethernet Shield = Xport Shield (der auch auf GND der Logamatic liegt) und habe deshalb mal das Ethernet abgestöpselt. bringt aber dieselben Fehler. Ich warte mit dem KM217 noch ein bisschen, da ich sowieso bald noch diverse SO-Zähler anbinden will. Irgendwie will ich das alles miteinander verBUSen und dann auf einen gemeinsamen xport gehen (der dann nicht auf dem km271 verbaut wird). Habe da sowieso meine Bedenken. der xport ist zwar extended temp. range, aber da wir im winter rohrleitungsbedingt den kessel hoch fahren wird es in der logamatic schon recht warm drin. Gruss, Malte
Moin. ich habe jetzt mein erstes CAN-IO-Modul fertig. Die eigentliche Funktionalität wird über Steckmodule realisiert, die dann auf die Ports auf der rechten Seite geroutet werden. Auf dem Bild befindet sich ein I2C-Steckmodul um externe Temperatursensoren auszulesen. Für die RC30 kommt dann die entsprechende Funktionalität auf die Steckmodule. @IngoF Gibt es etwas neues bei der Sendefunktionalität ?
Hallo Rudi, das sieht ja schon mal echt super aus.... Also habe auch mal inzwischen überhaupt nachgedacht was ich so machen möchte, und da wäre die Kommunikation über ein CAN-Modul echt klasse. Würde Dir sofort so einen Satz abkaufen wenn das Möglich wäre... Was ist das dort denn alles für Hardware drauf, Womit sind die Erweiterungsstifte belegt? Wie sind die 4 Stifte auf beiden Seiten belegt? die rechten 4 gehen vermutlich auf den Erweiterungsstecker. links gehen zumindest zwei für den CAN-Bus raus und die anderen beiden sind die Stromversorgung? Wie programmierst Du denn die Harware? ist der Stecker auf der anderen Seite oder wird das über die Erweiterungsstecker realisiert? Wie würdest Du denn die EMS-Telegramme über den CAN-Bus übertragen? Hast Du Dir da schon was überlegt? Also mit der Sendefunktion muss ich gestehen dass ich mich damit aus verschiedenen Gründen noch nicht mit beschäftigen konnte. Müsste also noch Dein C-Programm auf Assembler umschreiben damit ich dann einen Pin vom µC als Sendepin gebrauchen könnte.. (Also wäre die Information schon ganz schön wie Dein Modul belegt ist.. Müsste dass dann ja nicht nochmal neuerfinden...) Unter anderen ist auch alle paar Tage ein Heizungsfachmann da und tauscht wie wild alle Komponenten weil die Fehlermeldung 2L 266 von Buderus alles andere als präzise ist. Und mit den Log habe ich auch noch nicht viel bei dieser Störung anfangen können. Wäre ja auch zu einfach wenn Buderus irgendwelche Daten zur Fehleranalyse über den Bus jagen würde... Gruß Ingo
> Würde Dir sofort so einen Satz abkaufen wenn das Möglich wäre... Ist noch alles Prototype, es gibt noch einige Fehler im Layout. Theoretisch aber kein Problem. > Was ist das dort denn alles für Hardware drauf Ein ATMEGA328P, 23K256 SRAM/SPI, AT24C512B EEProm/I2C, MCP2551 CAN-Bus-Treiber, MCP2515 CAN-Bus-Controller, DC/DC für etwa 8-30V am Eingang. Die Schaltung soll dann mit 3V3 laufen. > Womit sind die Erweiterungsstifte belegt? Wie sind die 4 Stifte auf > beiden Seiten belegt? die rechten 4 gehen vermutlich auf den > Erweiterungsstecker. Auf der rechten Seite ist eine 4x4 Matrix die über die Erweiterungsplatine belegt wird. > links gehen zumindest zwei für den CAN-Bus raus und die anderen beiden > sind die Stromversorgung? Ja, das ist die 4x Wago-Klemme die auch auf der rechten Seite passt wenn man nur 4 oder weniger Leitungen braucht. > Wie programmierst Du denn die Harware? Auf der Unterseite befindet sich noch eine FFC, der dann per Kabel auf einen Miniadapter geht und dann auf den 6-Pol AVR Programmieradapter. Im Betrieb geht dann das Update über CAN-Bus. Deswegen auch das externe EEProm. > ist der Stecker auf der anderen Seite oder wird das über die > Erweiterungsstecker realisiert? Der "kleine" Erweiterungsstecker links ist für das Frontpanel, also 4x IO, VCC und dann für Debug noch UART. > Wie würdest Du denn die EMS-Telegramme über den CAN-Bus übertragen? Hast > Du Dir da schon was überlegt? Nein, das kommt dann aber später. Ich fange erstmal mit externen Temperatursensoren an (I2C). Die Werte werde ich wohl alle einzeln verschicken, mit Timestamp. Der CAN-Bus kann ja nur maximal 8 Bytes Payload. > Also mit der Sendefunktion muss ich gestehen dass ich mich damit aus > verschiedenen Gründen noch nicht mit beschäftigen konnte. Müsste also > noch Dein C-Programm auf Assembler umschreiben damit ich dann einen Pin > vom µC als Sendepin gebrauchen könnte.. (Also wäre die Information schon > ganz schön wie Dein Modul belegt ist.. Müsste dass dann ja nicht nochmal > neuerfinden...) Ja, die Info kann ich nachreichen, ich denke ohne diesen ServiceKey wird das erstmal nichts mit senden. > Unter anderen ist auch alle paar Tage ein Heizungsfachmann da und > tauscht wie wild alle Komponenten weil die Fehlermeldung 2L 266 von > Buderus alles andere als präzise ist. Und mit den Log habe ich auch noch > nicht viel bei dieser Störung anfangen können. Wäre ja auch zu einfach > wenn Buderus irgendwelche Daten zur Fehleranalyse über den Bus jagen > würde... Aha, dann soll er mal den ServiceKey für einen Tag da lassen, wenn die den überhaupt haben.
Hi Hier ist ein Artikel über die KM271 (Nachbau) http://wiki.neo-soft.org/index.php/Heizungsschnittstelle/Logamatic2107/K4 Ich hoffe, das hilft etwas. Gruss
Hallo Rudi, die Antwort der Mail kam nicht an weil der Host nicht erreichbar ist. Also meine Heizung läuft wieder.. es war die Pumpe. Mein AVR Studi lies sich nicht mehr starten, updaten, deinstalllieren oder reparieren. Hat einige Zeit gedauert bis ich mein AVR-Studio wieder am laufen hatte. Inzwischen habe ich erfolgreich Deinen C-Code ähnlich auf Assembler portiert. Meine LED blinkt nur noch wenn Nutzdaten fließen. Habe eine Automatische beatwortung der Pollings der Adress 0x21 eingebaut udn getestet. Nur dumm dass ich Meine Schaltung dabei geschossen habe.. Werde mir das noch mal ansehen müssen.. Ansonsten wäre ein Schaltplan Deiner Entwickling ganz interessant.. Gruß IngoF
Hallo, > die Antwort der Mail kam nicht an weil der Host nicht erreichbar ist. Ja, eine alte E-Mail Adresse. Sollte wieder funktionieren. > Also meine Heizung läuft wieder.. es war die Pumpe. Aha, das hättest du am Druck sehen können ;-). Wenn beim Einschalten der Druck nicht etwas hoch geht, dann ist da etwas faul. Ich sehe eine Druckänderung auch beim Umschalten auf WW <=> HK. > Meine LED blinkt nur noch wenn Nutzdaten fließen. Habe eine Automatische > beatwortung der Pollings der Adress 0x21 eingebaut udn getestet. Nur > dumm dass ich Meine Schaltung dabei geschossen habe.. Werde mir das noch > mal ansehen müssen.. Evtl. ist auch nur die Diode zu warm geworden und abgeraucht. Ich habe da 3 parallel geschaltet um das Wäremeproblem zu lösen. > Ansonsten wäre ein Schaltplan Deiner Entwickling ganz interessant.. Mal schaun, da muss ich noch aufräumen (Baustelle).
@Ingo F. Hast du die Möglichkeit auf dem internen Bus zu messen, also die Kommunikation zwischen den einzelnen Modulen und nicht am Klinkenstecker? Ich habe noch 2 Schaltungen vom EI-Bus gefunden: http://www.freebus.org/index.php/de/hardware-mainmenu-36/grundschaltung-mainmenu-26 http://www.freebus.org/index.php/de/signale-mainmenu-28 Sieht in etwa so aus was wir brauchen.
Denke die Shaltung ist doch schon ganz gut. Die Schaltung war nicht das Problem. Hatte mich nur beim umlöten im Kabel vergriffen und deswegen lief nichts mehr. Nur habe ich im Moment ein Problem mit Assembler. Mit AVRStudio und HAPSIM funktioniert die Simulation fehlerfrei. Aber auf der "echten" Platine wird seltsamerweise immer ein zusätzliches 0x00-Byte gesendet das eigentlich nie gesendet wird. Mit der älteren hex-Datei funktioniert alles und habe nur keinen Quelltext mehr. Bin gerade bei der Fehlersuche udn versuche die neue Version zurückzuentwickeln bis es wieder läuft. Gruß Ingo
Hallo Rudi, Die Antwortfunktion habe ich jetzt getestet. Habe einfach alle Polling von 0xA1 <break> mit 0x21 <Break> beantwortet und konnte in der RC30 den Busteilnehmer "Mischer 33" im Display sehen können. Allerdings gefällt mir die Schaltung noch garnicht. Mein Transistor sperrt nicht richtig und zieht den Bus schon 1-2 Volt runter und der Transistor hat etwa 70°C und die Z-Diode 90°C wenn nciht gesendet wird. Irgendwie Schaltet der TRansistor schon teilweise bei 0,5 Volt durch. Habe auch eine Diode davor gesetzt um die Ansprechspannung zu reduzieren. Muss mir mal die Schaltung seperat aufbauen und durchtesten. Eigentlich müsste der Basiswiderstand richtig berechnet sein. aber irgendwie läuft da was schief. Wenn der Transistor durchgeschaltet hat wird Busspannung wie gewünscht auf 10 Volt heruntergezogen. Die Telegramme die ich sende werden über den Bus automatisch eingelesen. Kann dadurch erkennen dass größtenteils die Telegramme richtig durchgehen, aber ab und zu die Adresse verfälscht wird. Als ob irgendjemand dazwischen sendet. Deine Mail scheint immer noch nicht zu funktionieren... Gruß Ingo
> Die Antwortfunktion habe ich jetzt getestet. Habe einfach alle Polling > von 0xA1 <break> mit 0x21 <Break> beantwortet und konnte in der RC30 den > Busteilnehmer "Mischer 33" im Display sehen können. Nicht schlecht! > Allerdings gefällt mir die Schaltung noch garnicht. Mein Transistor > sperrt nicht richtig und zieht den Bus schon 1-2 Volt runter und der > Transistor hat etwa 70°C und die Z-Diode 90°C wenn nciht gesendet wird. Die Temperaturprobleme hatte ich nur an der Diode (jetzt sind es 3). Ich bekomme demnächst eine 5W Diode die ich dort verbauen werde (die Schaltung mit den Mosfet). > Die Telegramme die ich sende werden über den Bus automatisch eingelesen. > Kann dadurch erkennen dass größtenteils die Telegramme richtig > durchgehen, aber ab und zu die Adresse verfälscht wird. Als ob > irgendjemand dazwischen sendet. Das habe ich auch gesehen, siehe Beitrag "Re: Logamatic 2107 Schnittstelle". Ich bin mir nicht sicher ob die Sendeschaltung so richtig ist, denn auf der RC3X Platine kann ich kein Bauteil finden das annähernd 1.5W verträgt. Der Bus vom Klinkenstecker (BC10) ist direkt mit dem internen Bus verbunden, also keine Schutzschaltung etc.. Die Schutzbeschaltung muss dann unbedingt mit in die externe Schaltung. > Deine Mail scheint immer noch nicht zu funktionieren... Doch, die funktioniert jetzt.
Hallo Rudi, das Problem mit der Sendeschaltung habe ich gelöst. War nur so blöd dass ich Emitter und Collector vertauscht hatte. Ein Wunder dass die Sendeschaltung überhaupt lief. Die Z-Diode und Transistor werden jetzt wie erwartet garnicht mehr warm. Wenn ich jetzt immer permanent die das Polling der Adress 33(0x21) mit 0x21 <brk> beantwort erscheint auch die Adresse im RC30 Bus-Status. Die Adresse erscheint nach dem ersten Polling welches etwa alle 20-30 Sekunden widerholt wird. Sobald die erste Antwort kommt wird die 0x21 auch wie die anderen Busteilnehmer mehrmals gepollt. Die RC30 versucht dann widerholt ein Kommando ohne Polling-Bit an die 0x21 zu schicken und erwartet vermutlich dass irgendwann die 0x21 auch irgendwann mal ein Pieps sagt. Sonst kann ich mir nicht erklären warum der wie bekloppt immer das selbe Telegramm an die 0x21 schickt. Nur was mir nicht so ganz gefällt ist dass Byte UBA3/MC10 (0x08) oder von der BC10 (0x09) immer widerholt wird. Vermute mal ganz ohne Oskar kommt man da nicht weiter. Irgendwie muss sich ja die Signalform der RC30 und meiner Sendeschaltung unterscheiden. Jetzt wäre es mal ganz interessant von einem Service-Key-Besitzer zu wissen mit welcher Adresse sich der Service-Key anmeldet. hier jetzt mal ein kurzer Mitschnitt vom Bus:
1 | {--} 16:20:32 15.07.10: A1
|
2 | {--} 16:20:32 15.07.10: 21 21
|
3 | {--} 16:20:32 15.07.10: 00
|
4 | {--} 16:20:32 15.07.10: 89
|
5 | {--} 16:20:32 15.07.10: 09
|
6 | {--} 16:20:32 15.07.10: 8B
|
7 | {--} 16:20:32 15.07.10: 89
|
8 | {--} 16:20:32 15.07.10: 09
|
9 | {--} 16:20:32 15.07.10: 8C
|
10 | {--} 16:20:32 15.07.10: 89
|
11 | {--} 16:20:32 15.07.10: 09
|
12 | {--} 16:20:32 15.07.10: 90
|
13 | {1A} 16:20:32 15.07.10: 10 21 AC 00 00 00 00 1A
|
14 | {1A} 16:20:32 15.07.10: 10 21 AC 00 00 00 00 1A
|
15 | {1A} 16:20:32 15.07.10: 10 21 AC 00 00 00 00 1A
|
16 | {--} 16:20:32 15.07.10: 10
|
17 | {BA} 16:20:32 15.07.10: 08 00 18 00 5A 02 C1 64 64 0A 10 E5 60 80 00 02 0C 02 72 00 84 0F 3D 48 00 C9 FF 03 00 BA
|
18 | {--} 16:20:32 15.07.10: A1
|
19 | {--} 16:20:32 15.07.10: 21 21
|
20 | {--} 16:20:32 15.07.10: 89
|
21 | {--} 16:20:32 15.07.10: 09
|
22 | {--} 16:20:32 15.07.10: 8D
|
23 | {--} 16:20:32 15.07.10: 89
|
24 | {--} 16:20:32 15.07.10: 09
|
25 | {--} 16:20:32 15.07.10: 8E
|
26 | {--} 16:20:32 15.07.10: 89
|
27 | {--} 16:20:32 15.07.10: 09
|
28 | {--} 16:20:32 15.07.10: 90
|
29 | {1A} 16:20:32 15.07.10: 10 21 AC 00 00 00 00 1A
|
30 | {1A} 16:20:32 15.07.10: 10 21 AC 00 00 00 00 1A
|
31 | {1A} 16:20:32 15.07.10: 10 21 AC 00 00 00 00 1A
|
32 | {--} 16:20:32 15.07.10: 10
|
33 | {2F} 16:20:32 15.07.10: 08 00 18 00 5A 02 C3 64 64 0A 10 E5 60 80 00 02 0C 02 73 00 82 0F 3D 48 00 C9 FF 03 00 2F
|
34 | {--} 16:20:32 15.07.10: A1
|
35 | {--} 16:20:32 15.07.10: 21 21
|
Das erste Byte in Klammern ist meine errechnete CRC und das letzte Byte ist dann die übertragene CRC. Beim Polling gibt es ja keine CRC. Gruß Ingo
> Die RC30 versucht dann widerholt ein Kommando ohne Polling-Bit an die > 0x21 zu schicken und erwartet vermutlich dass irgendwann die 0x21 auch > irgendwann mal ein Pieps sagt. Sonst kann ich mir nicht erklären warum > der wie bekloppt immer das selbe Telegramm an die 0x21 schickt. > {1A} 16:20:32 15.07.10: 10 21 AC 00 00 00 00 1A Ich geh mal davon aus, das die 0x10 den Befehl absetzt. Es gibt eine Nachricht die in etwa so aussieht. Dort ändert sich ab und zu nur ein Bit, frag mich jetzt nicht welche ... :-/ Von Mario kam weiter oben noch diese Nachricht: > 21 ist der Absender MM10 (Pumpe und Mischer Heizkreis 2) > Beispiel: > 21 00 AB 00 05 00 CD 00 9C 01 10 F9 00 > Byte 4 : Vorlauf HK2 SOLL > Byte 5+6: Vorlauf HK2 IST > Byte 8 : Mischersteuerung Hallo Mario, hast du noch ein paar Telegramme von Adresse 0x21 ??????? Mal schaun ;-)
Angehängte Dateien:
-
bs_0001.png
1,2 MB -
bs_0002.png
1,2 MB -
bs_0003.png
1,2 MB -
bs_0004.png
1,2 MB -
ts_0001.png
1,2 MB -
ts_0002.png
1,2 MB -
ts_0003.png
1,2 MB -
ts_0004.png
1,2 MB -
ts_0005.png
1,2 MB
Anbei die Bilder der BC10. Vom Klinkenstecker gehen die Daten OHNE Schutz auf den Bus.
Mathias K. schrieb: > Das habe ich auch gesehen, siehe > Beitrag "Re: Logamatic 2107 Schnittstelle". Hallo Rudi, das hatte ich ja damals auch an Deinen Oszillogrammen gesehen das dort manchmal ein Byte widerholt wurde. > Ich bin mir nicht sicher ob die Sendeschaltung so richtig ist, > denn auf der RC3X Platine kann ich kein Bauteil finden das > annähernd 1.5W verträgt. Sieht so aus als ob Buderus das egal ist. Die MC10 ist da etwas radikaler mit dem Bus. Der Transistor T1 hängt direkt am Bus und spielt "regelbarer Kurzschluß". Wenn T2 durch TX-Pin=0 sperrt liegt die Basis von T1 über 4,7 kOhm auf +5V. Wenn mann mal 1 Volt für UBE abzieht fließen hier 0,85mA in die Basis bei einem hfe von 200 bis 450 müssten dann etwa 170 bis 390mA durch den armen Kerl gejagt werden. Laut Datenblatt liegt Ptot bei 200mW. Wenn man jetzt mal den schlimmsten Fall annimmt liegen kurzzeitig 3,9W an dem T1. Da er aber wohl nur kurz angesteuert wird und längere Ruhepausen hat wird der wohl noch überleben ohne gleich zu "verdampfen". Also bevor ich meinen Collector/Emitter vertauscher bemerkt habe wurde kein einziges Byte widerholt. Es kam nur mal vor dass manchmal ein Byte nicht richtig gesendet wurde. Nach der Korrektur des Fehlers wurde permanent die 0x21 widerholt. Bei Deinen Oszillogrammen wurde teilweise was widerholt. Deswegen vermute ich dass man den Bus garnicht soooo stark belasten muss und auf 10 Volt herunterziehen muss. Werde das mal testen indem ich noch ein paar Dioden dazwischen hänge... Gruß Ingo
Habe es noch mal getestet und scheint wirklich so zu sein. Habe noch zwei 1N4148 dazwischen geschaltet und es lief ganz ohne irgendwelche Echos. Bei meiner Version habe ich alse 4x1N4148 und eine 8,2Volt Z-Diode inkl. Transistor (im Moment BCP68). Wenn ich zwei 1N4148 weglasse kommen immer Echos. Gruß Ingo
Also etwa 12V ? Versuch doch mal die 12V zu schalten und nicht GND !?
Rudi schrieb: > Also etwa 12V ? Versuch doch mal die 12V zu schalten und nicht GND !? Habe noch nicht nachmessen können wieviel Volt es wirklich sind. Müssten aber geschätzte 12 Volt sein. Gegen 12 Volt kann ich nicht schalten weil ich nicht an der Service-Buchse hänge sondern parallel zur RC30 im Wohnzimmer. Vielleicht würde es ja auch mit drei Dioden laufen. Habe ich aber (noch) nicht getestet. Das wäre vielleicht eine Erklärung warum der T1 nicht abraucht weil nur gegen 12 Volt geschaltet wird... Allerdings soll die RC30 doch den Pegel auch auf 10 Volt herunterziehen? Oder war da noch irgendein Offset am Oskar eingestellt? Gruß Ingo
> Das wäre vielleicht eine Erklärung warum der T1 nicht abraucht weil nur > gegen 12 Volt geschaltet wird... Allerdings soll die RC30 doch den Pegel > auch auf 10 Volt herunterziehen? Oder war da noch irgendein Offset am > Oskar eingestellt? Nein, da war kein Offset. Das Signal liegt bei 12V +-2.5V. Evtl. springt dein Komparator nicht mehr an und du siehst aus diesem Grund kein Echo bzw. dein eigenes Signal?
Rudi schrieb: > bzw. dein eigenes Signal? Verdammt.. habe ich nicht dran gedacht.. Nur ohne Oskar werde ich das wohl nie feststellen können ob ich mein Telegramm nicht mehr sehe oder das Echo. Der komperator liegt ja rechnerisch genau in dem Bereich... Gruß Ingo
Angehängte Dateien:
-
hkww0001.png
33 KB -
hkww0002.png
28 KB -
hkww0003.png
26 KB
Hallo, ich habe mal ein wenig mit meinem Master gespielt, der mir die Daten in quasi Realtime visualisieren soll. Anbei ein paar Bilder mit dem Flot-Renderer im Browser. Ganz nett das Teil, muss man ja mal sagen. Grüße.
Hi Rudi, Jepp das flot taugt schon was, hab das in meinem Stromzaehler-Visualisierungs-Projekt drin. Habe das Hardwarelayout nochmal überarbeitet für den KM271 Clone. Also den analogpart schön zusammengepfercht, kurze Leiterbahnen und ohne grosse Massefläche. Dann den Xport mit Spannungsregler getrennt auf der anderen Seite. RX/TX sind ueber Jumper verbunden, zum Test habe ich die beiden Pins erstmal getrennt. Eben getestet und ich könnte kotzen. Zunächst waren die angezeigten Temperaturen mit am Ethernet angeschlossenen xport "nur" um -3°C verfälscht. "schön" dachte ich und bin ne weile neben dran gestanden. Nach etwa einer Minute der Supergau: * Kesseltemperatur von 58° auf 22° gefallen * Warmwasser von 49° auf 16° * Aussentemperatur von 22° auf 16° (die stimmt eh nicht immer, da das Sensorgehäuse manchmal "besonnt" wird So langsam habe ich das gefühl als ob die 80-120 mA vom xport zuviel für die logamatic sind. Spannungseinbruch mit/ohne xport ist nur ca 50 mV. An der Ethernet-Masseverbindung kann es nicht liegen (unshielded rj45 connector) Falls jemand noch eine Idee hat, her damit, ansonsten werde ich demnaechst viel Kaffee kochen und die verbindung zwischen xport und logamatic per optokoppler trennen und dem xport eine eigene spannungsversorgung verpassen. Gruss, Malte
Hallo, > Jepp das flot taugt schon was, hab das in meinem > Stromzaehler-Visualisierungs-Projekt drin. Wie greifst du den Zähler ab ? Optisch ? Selbst gebaut ? Ich habe meinen CAN-Bus am Zähler vorbei gezogen, mir fehlt da eigentlich nur die richtige Optik. > Falls jemand noch eine Idee hat, her damit, ansonsten werde ich > demnaechst viel Kaffee kochen und die verbindung zwischen xport und > logamatic per optokoppler trennen und dem xport eine eigene > spannungsversorgung verpassen. Hast du das schon probiert ? Was passiert wenn du einen 42 Ohm / 1W Widerstand, anstatt des X-Ports als Verbraucher benutzt ? Optokoppler sind bei Heizungen immer eine gute Idee. In der KM271 benutze ich den ILD213T für 38400 Baud. Grüße.
Hi, > Wie greifst du den Zähler ab ? Optisch ? Selbst gebaut ? Ich habe meinen > CAN-Bus am Zähler vorbei gezogen, mir fehlt da eigentlich nur die > richtige Optik. Ich habe hinter die Abrechnungszaehler diese Hutschienenzaehler mit SO Impulsausgang montiert. Also digitale Impulszählung. Rumgebastle mit Optokoppler zum Erfassen des "zählerrades" war mir zu blöd. vor allem weil ich mich auf die werte verlassen will die da gezaehlt werden ;) > Hast du das schon probiert ? Was passiert wenn du einen 42 Ohm / 1W > Widerstand, anstatt des X-Ports als Verbraucher benutzt ? nein, probiert hab ichs noch nicht. Ich wollte heute noch probieren was passiert wenn ich dem xport ne externe spannungsversorgung gebe und nur GND, RX/TX zur logamatic verbinde. Das mit dem Widerstand als Last probier ich dann gleich mit... wenns dann immer noch nicht haut trenne ich das ganze galvanisch. > Optokoppler sind bei Heizungen immer eine gute Idee. In der KM271 > benutze ich den ILD213T für 38400 Baud. hab hier noch cny75, ltv 845 und ilq1 rumfliegen. einer davon wird wohl für die 2400 baud taugen. Gruss, Malte
Hallo, habe inzwischen ein paar Omis die Handtaschen geklaut und mir inzwischen ein DigitalOszilloskop gekauft und werde mal sehen wass denn so meine Sendeschaltung mit dem Bus uberhäupt veranstaltet. Malte Bayer schrieb: >> Wie greifst du den Zähler ab ? Optisch ? Selbst gebaut ? Ich habe meinen >> CAN-Bus am Zähler vorbei gezogen, mir fehlt da eigentlich nur die >> richtige Optik. > Ich habe hinter die Abrechnungszaehler diese Hutschienenzaehler mit SO > Impulsausgang montiert. Also digitale Impulszählung. @Rudi hatte irgendwie im Hinterkopf dass Du schon Deinen Stromzähler in deine Kurven integriert hattest. Aber das war wohl der Gaszähler. Wie hast Du die denn die Werte vom Gaszähler bekommen? Was selbstgebautes? Oder vom Gasversorger schon was eltronisches bekommen? Gibt es sowas denn in elektronisch? Also bei Die Idee mit dem Stromzähler hinter dem Abrechnungszähler gefällt mir schon ganz gut.... @Malte Die Umwandlung des SO-Impulsausgang in Zählerwerte hast Du dann bestimmt mit einer Eigenentwicklung realisiert, oder wie machst Du das? Hatte auch mal überlegt den Stromversorger zu wechseln und mir einen eletktronischen Stromzähler einbauen zu lassen. Allerdings hätten dann die Mehrkosten für den elektronischen Zähler die Ersparnise vom Wechsel wieder aufgefressen. Die Werte würde man dan über Google bekommen. Allerdings war mir nicht so wohl dabei Google meine Stromzählerwerte zu überlassen..... Gruß Ingo
Hi Ingo, naja, das device von mir zaehlt einfach auf (momentan 8) kanaelen die impulse. ein daemon am server pollt diese zaehlerstaende alle 60 sek, beim pollen werden diese dann auf 0 zurueckgesetzt. Nachher in der Auswertung sehe ich so relativ genau über den tag (woche/monat/jahr/whatever) den verbrauch als kurve. Berechnung in "ca Watt" habe ich so realisiert: #define FLUX_RESOLUTION><------>800<---><------>// SO Counter resolution #define FLUX_LIVE_DELTA><------>60<----><------>// seconds interval for calculating the live value #define FLUX_LIVE_FACTOR<------>(1000UL * 3600UL / (FLUX_LIVE_DELTA) / (FLUX_RESOLUTION)) Berechnung des relativen Last (über zb 60 sekunden gemessen) wäre dann: P = 60_SEC_TICK_COUNT * FLUX_LIVE_FACTOR Um den Zählerwert auszurechnen braucht man lediglich alle gezaehlten ticks durch die Resolution teilen. Idr. haben die Zähler 800/1000/2000 Ticks pro KWh Gruss, Malte
@Ingo > hatte irgendwie im Hinterkopf dass Du schon Deinen Stromzähler in deine > Kurven integriert hattest. Aber das war wohl der Gaszähler. > Wie hast Du die denn die Werte vom Gaszähler bekommen? Was > selbstgebautes? Oder vom Gasversorger schon was eltronisches bekommen? > Gibt es sowas denn in elektronisch? Selbst gebaut. Die haben einen Magneten im Gehäuse und ich messe den über einen Hal-Sensor, also auch wieder Impulse pro Umdrehung. @Malte Wieviel hast du denn in einen Stromzähler investiert ? Ich habe den bisher billigsten (30€) hier gefunden: http://www.energie-zaehler.com/epages/61422236.sf//de_DE/?ObjectPath=/Shops/61422236/Products/kwh-meter Im Vergleich zu einem Selbstbau, ich bräuchte 4, noch im Preisrahmen.
Hallo da ich selber Entwickler bin und und solche auch unterstützen möchte, biete ich bei einer Bestellung der oben genannten Zähler, mit Angabe "Logamatic 2107 Schnittstelle" im Bestelltext einen Rabat von 10%. Ich hoffe das diese Information nicht gegen die Forum-Regeln verstößt. Grüße JoS0
Johann Stark schrieb: > biete ich bei einer Bestellung der oben genannten Zähler, mit Angabe > "Logamatic 2107 Schnittstelle" im Bestelltext einen Rabat von 10%. Das Gilt vermutlich nicht für diesen den Drehstromzähler, oder? http://www.energie-zaehler.com/epages/61422236.sf//de_DE/?ObjectPath=/Shops/61422236/Products/EEM34DLC Rudi schrieb: > Selbst gebaut. Die haben einen Magneten im Gehäuse und ich messe den > über einen Hal-Sensor, also auch wieder Impulse pro Umdrehung. Habe mich mal gerade Schlau gemacht und einen Reedkontakt genau für meinen Gaszähler gefunden: http://www.pipersberg.de/Gaszahler/RF1-Impulsnehmer.pdf Habe die gerade mal angemailt. Was soll ich da selber ein Reed-Relais reinbasteln wenn es schon was fertiges gibt. (Wenn der nicht zu teuer ist) Habe inzwischen etwas an meiner Sendeschaltung herumgebastelt und versucht mein Signal soweit wie möglich an dem Sendesignal der anderen Busteilnehmer anzupassen. Seltsamerweise werden aber immer die Bytes widerholt. Na vielleicht wird die Sendeschaltung doch erst noch mal vertagt. Gruß Ingo
IngoF schrieb: > Das Gilt vermutlich nicht für diesen den Drehstromzähler, oder? > http://www.energie-zaehler.com/epages/61422236.sf/... Oder eben diese Version mit nur halben Stromverbrauch? Das Gilt vermutlich nicht für diesen den Drehstromzähler, oder? http://www.energie-zaehler.com/epages/61422236.sf/...
Ups.. Copy & Paste Fehler.... Den meinte ich: http://www.energie-zaehler.com/epages/61422236.sf//de_DE/?ObjectPath=/Shops/61422236/Products/%22461060b%20EEM12-65A%22
Hallo die Schell Count Zähler sind im Moment nicht lieferbar, aber die Saia Burgess Zähler sind baugleich, bis auf den Wechselstrom/32 A der 2000 Imp/kWh hat. Die anderen haben alle 1000 Imp./kwh. Aber grundsätzlich, wenn es um dieses Projekt geht bitte um Anfrage und ich sehe was ich tun kann. Wir sind mehr als nur ein Onlineshop. Der zuletzt gennante Zähler ist ein Wechselstromzähler! Grüße J0S0
@IngoF > Habe mich mal gerade Schlau gemacht und einen Reedkontakt genau für > meinen Gaszähler gefunden: > http://www.pipersberg.de/Gaszahler/RF1-Impulsnehmer.pdf > Habe die gerade mal angemailt. Was soll ich da selber ein Reed-Relais > reinbasteln wenn es schon was fertiges gibt. (Wenn der nicht zu teuer > ist) Ich habe mir eine schmale Platine gebaut, mit einem digitalen HAL-Sensor und 2 passiven Bauteilen. Das geht relativ einfach, passt auch bei unterschiedlichen Zählern und läuft direkt mit 3V3. Mehr als 15€ würde ich für einen fertigen mit Gehäuse und OpenDrain-Ausgang nicht bezahlen. > Habe inzwischen etwas an meiner Sendeschaltung herumgebastelt und > versucht mein Signal soweit wie möglich an dem Sendesignal der anderen > Busteilnehmer anzupassen. Seltsamerweise werden aber immer die Bytes > widerholt. Na vielleicht wird die Sendeschaltung doch erst noch mal > vertagt. Das gleiche Problem habe ich hier auch ... Ich schreib grad einen Parser für die Nachrichten in C um die Werte auf dem CAN-Bus zu haben. Anbei noch ein paar Erkenntnisse zu den Nachrichten (Vervollständigung erwünscht):
1 | 08 00 34 00 32 01 db 01 dc 21 00 00 03 00 01 b3 d2 00 0e a7 00 11 |
2 | |
3 | W1 W2 W2 W3 W3 W4 ?? ?? ?? ?? W5 W5 W5 W6 W6 W6 ?? |
4 | |
5 | W1: WW soll (Tag/Nacht) |
6 | W2: WW Temperatur |
7 | W3: WW Temperatur |
8 | W4: Status |
9 | |
10 | * bit |
11 | * 0 0: night, 1: day |
12 | * 1 ? |
13 | * 2 ? |
14 | * 3 heating |
15 | * 4 ? |
16 | * 5 1: normal operation ? |
17 | * 6 ? |
18 | * 7 ? |
19 | |
20 | W5: WW Aufbereitungszeit |
21 | W6: unbekannter Zähler |
Hi Rudi, > Wieviel hast du denn in einen Stromzähler investiert ? Ich habe den > bisher billigsten (30€) hier gefunden: > http://www.energie-zaehler.com/epages/61422236.sf//de_DE/?ObjectPath=/Shops/61422236/Products/kwh-meter > > Im Vergleich zu einem Selbstbau, ich bräuchte 4, noch im Preisrahmen. Bei mir waren es 8x 17€. Allerdings wahrscheinlich nicht direkt mit dem von dir gefundenen Zähler vergleichbar: Meine verbauten Zähler sind 10A Typen, http://www.top-messtechnik.com/jtlshop/index.php?a=475 Das Angebot von Johann Stark für die 25A Version -10% finde ich auch interessant, wären dann +10€ für +15A ;) Die Adresse werde ich mir auf jeden Fall merken für die nächste grössere Bestellung (Rechnungszahlung und grössere Produktpalette in diesem Bereich) :) PS: um mal wieder komplett zum Thema zurück zu kommen: Das Netzteil der Logamatic scheine ich nicht zu überlasten. Habe mal mit einem Widerstand anstatt 3.3vreg+xport gespielt -> alles scheint korrekt. Entweder der Spannungsregler oder der xport ziehen mir die Masse hoch. Ich tippe wohl eher auf den Spannungsregler. Also, externes Netzteil ist der nächste Test... Gruss, Malte
Angehängte Dateien:
-
km271_test.png
4,6 KB
@Malte Bayer > PS: um mal wieder komplett zum Thema zurück zu kommen: > Das Netzteil der Logamatic scheine ich nicht zu überlasten. Habe mal mit > einem Widerstand anstatt 3.3vreg+xport gespielt -> alles scheint > korrekt. > Entweder der Spannungsregler oder der xport ziehen mir die Masse hoch. > Ich tippe wohl eher auf den Spannungsregler. Welchen Regler benutzt du ? Anbei die Analog-Schaltung die ich aus den Bildern sehe. Die KL1 Nummern stimmen nicht mit deinen überein. Mein S1 ist der linke Kontakt auf der Oberseite und S2 auf der Unterseite usw..
@Malte Bayer Ich seh grad die ist identisch zu deiner Schaltung. Der analoge Teil ist also komplett unabhängig vom digitalen Teil. Du solltest die beiden Teile auch unabhängig in Betrieb nehmen können.
Rudi schrieb: > Ich schreib grad einen Parser für die Nachrichten in C um die Werte auf > dem CAN-Bus zu haben. Wie willst Du denn die Werte im CAN Bus übertragen? Der Zeitstempel muss ja nicht mitgesendet werden. Reicht doch wenn man beim schreiben in die Datenbank die aktuelle Zeit nimmt. In meiner SQL-Datenbank habe ich nur zwei Tabellen einmal mit Tiny und SmallInt. Darin wird nur der Zeitstempel, der Wert und eine ID gespeichert. Die Umrechnung passiert im Moment noch in meinem Programm. Wollte mir eventuell noch eine Tabelle basteln in der ich dann zu jeder Werte-ID die Berechnung und weitere Informationen wie Bemerkungen u.s.w speichere. Man könnte doch einfach in einem Telegramm mehrere Werte übermitteln die sich geändert haben. Ungeänderte Werte werden natürlich nur gesendet wenn sie sich nach einer Virtelstunde immer noch nicht geändert haben sollten. Also Einfach im CAN-Telegramm als erstes die Werte-ID und dann den Wert. Vielleicht könnte man ja eine gemeinsame Werte-ID-Tabelle erstellen. Dann könnte man einfach in einer Tabelle die Werte sammeln und neue ergänzen wenn man neue Werte gefunden hat. Hier mal ein Beispiel der ersten Daten deines Beispieltelegrammes:
1 | ID Quelle Ziel Telegrammtyp Start Bit Bytes Divisor Linie Bemerkung |
2 | 01 08 00 34 4 0 1 1 1 SollTemperatur |
3 | 02 08 00 34 5 0 2 10 1 Warmwasser Temperatur |
4 | 03 08 00 34 7 0 2 10 1 Warmwasser Temperatur #2 |
5 | 04 08 00 34 9 1 1 0 2 Tag/Nachtbetrieb |
6 | 05 08 00 34 9 4 1 0 2 Heizen |
7 | 06 08 00 34 9 6 1 0 2 Betriebsart |
Oder was haltet Ihr davon? Denke das ist eine relativ einfache Darstellungsform. Gut ohne viel Aufwand zu dokumentieren, oder? Die Tabelle dürfte selbsterklärend sein und für so ziemlich aller Werte verwendbar sein. @Rudi? Also der Impulgeber für meine Gasuhr soll inkl. Versand 34 Euro kosten. Überlege ob ich mir den doch bestelle. Habe heute mal mit einem simplen Reed-Kontakt versucht irgendein ergebnis zu bekommen. Allerdings scheint das Magnetfeld dafür zu schwach zu sein? Was hast Du denn für einen Hall-Sensor genommen? Gibt ja massenhaft Type von 1€ bis 40€ mit verschiedenen Ausgängen.
> Wie willst Du denn die Werte im CAN Bus übertragen? Der Zeitstempel muss > ja nicht mitgesendet werden. Reicht doch wenn man beim schreiben in die > Datenbank die aktuelle Zeit nimmt. Die ID wird im CAN-Header übertragen. Im Payload steht die Zeit und der eigentliche Wert. Die Zeit ist mir eigentlich sehr wichtig. Falls Buskollisionen auftreten kommen die Nachrichten nicht direkt an, sondern zeitversetzt. Für diesen Fall werden die zu sendenden Daten im externen SRAM gehalten und später gesendet. Für den Gaszähler (Impulsgeber) z.B. wichtig, für Temperaturen nicht unbedingt nötig. > Man könnte doch einfach in einem Telegramm mehrere Werte übermitteln die > sich geändert haben. Ungeänderte Werte werden natürlich nur gesendet > wenn sie sich nach einer Virtelstunde immer noch nicht geändert haben > sollten. Wenn du mehrere Werte überträgst, sendest du zwangsläufig auch Werte die sich nicht geändert haben. Du hast nur eine 24Bit ID und dann 8 Bytes Payload. Ich habe die ID etwas verkleinert und benutze die freien Bits als Kontrollbits. Dadurch kann ich die eigentlichen Daten, Befehle auf die Daten (Offset, Skalierung etc. für einen Temperatursensor mit einer bestimmten ID), einfache Befehle an eine CAN-Bus Modul verschicken und mir jede Nachricht optional bestätigen lassen (ACK). Ich kann über den Bus die einzelnen Module Parametrisieren und mit einer neuen Firmware bespielen und ich kann alle Sensoren an so einem Modul parametrisieren. > Also der Impulgeber für meine Gasuhr soll inkl. Versand 34 Euro kosten. > Überlege ob ich mir den doch bestelle. Habe heute mal mit einem simplen > Reed-Kontakt versucht irgendein ergebnis zu bekommen. Allerdings scheint > das Magnetfeld dafür zu schwach zu sein? Was hast Du denn für einen > Hall-Sensor genommen? Gibt ja massenhaft Type von 1€ bis 40€ mit > verschiedenen Ausgängen. 34€ ist doch schon was ;-). Ich benutze den AN48820a. Ich kann dir in etwa 2 Wochen meinen alten Sensor geben. Ich habe mir neue Platinen gebaut, aber noch nicht bestückt. > Oder was haltet Ihr davon? Denke das ist eine relativ einfache > Darstellungsform. Gut ohne viel Aufwand zu dokumentieren, oder? > Die Tabelle dürfte selbsterklärend sein und für so ziemlich aller Werte > verwendbar sein. Sieht doch gut aus. Was bedeutet Linie ? Divisor würde ich Skalierung nennen.
Rudi schrieb: > Wenn du mehrere Werte überträgst, sendest du zwangsläufig auch Werte die > sich nicht geändert haben. Nicht wie ich das meinte. wenn mann z.B. 6Byte Payload hätte könnte man zwei zweiByte Werte (Temperatur z.B.) übertragen mit der dazugehörigen ID senden. Wenn sich zwei Werte geändert haben werden mehrere gesendet. Kann ja sein dass sich in einem Telegramm mehrere Werte geändert haben. Aber wenn Du ja bei den Zeitstempel mitsendest wird es schon knapp mit den 8 Byte Payload. Rudi schrieb: > Ich kann dir in > etwa 2 Wochen meinen alten Sensor geben. Ich habe mir neue Platinen > gebaut, aber noch nicht bestückt. musst mir dann mal sagen was Du dafür bekommst. Würde ich glatt zuschlagen. Rudi schrieb: > Sieht doch gut aus. Was bedeutet Linie ? Divisor würde ich Skalierung > nennen. Das ist die Verbindungsart zwischen den Punkten. Bei Temperaturen ändert sich ja die Temperatur mehr oder weniger gleichmaßig und ändert sich nicht Stufenförmig. Bei gesetzten Werten wie die aktuelle Leistung oder Binären Werten ändert sich der Zustand ja Sprungartig. Also wird dort erst mal die Linie mit dem alten Wert gezeichnet und dann eine Linie nach oben oder unten. Rudi schrieb: > Du hast nur eine 24Bit ID Nein, im Moment habe ich nur eine 8Bit-ID. (erste Spalte) Bisher gibt es ja nur knapp über 20 auswertbare Werte der Heizung. Könnte vielleicht auf die Dauer etwas zu klein sein wenn noch andere Sensoren/Aktoren dazukommen Gruß Ingo
Hallo
Soory für die "Zwischenrufe", Stromzähler und so interessieren mich
auch.
Frage:
>Habe das Hardwarelayout nochmal überarbeitet für den KM271 Clone.
Ich hätte interesse für eine KM271 oder einen Clone.
Gibt es diesen irgendwo zu beziehen odern einen Plan ?
(Der einigermassen zu dem Ergebnis führt)
Frage: Hat das "interne" Protokoll etwas mit dem E-Bus zu tun ?
Gruss Karl
Huhu... Das zusammengefasste Zeug dazu ist hier: http://wiki.neo-soft.org/index.php/Heizungsschnittstelle/Logamatic2107/K4 Die Platine "Rev. C" funktioniert soweit, wenn man den kompletten Spannungsregler- und XPORT Teil nicht bestückt. RS232 funktioniert komischerweise. Schaltplan auf der Wikipage ist an sich auch okay (auf dem basiert das layout) Beziehen kann man das ding nicht (also von mir zumindest nicht)... Gruss, Malte
Rudi schrieb: > Die Zeit ist mir eigentlich sehr wichtig. Falls > Buskollisionen auftreten kommen die Nachrichten nicht direkt an, sondern > zeitversetzt. Für diesen Fall werden die zu sendenden Daten im externen > SRAM gehalten und später gesendet. Für den Gaszähler (Impulsgeber) z.B. > wichtig, für Temperaturen nicht unbedingt nötig. Also sooo lange wird es keine Buskollisionen geben, es sei denn der Bus wird mit langeren Firmwareuploads vollgepumpt. Für den Gas-/Stromzähler wollte ich die "intelligenz" in den SO-Bus Controller hängen der über den CAN-Bus angebunden ist. Er soll die Impulse zählen die in einer Minute eingegangen sind und dann daraus die richtigen Werte Berechnen. Entweder aus den Impulsabständen und/oder der Impulsanzahl innerhalb einer Minute. Aber ich kann erst sagen wenn ich richtige Signale vom Gas/Stromzähler bekomme ob das so geht. Mein Gaszähler gibt nur alle 0,1m³ ein Impuls. Wenn ich allerdings die "Spiegelfläche" auf der letzten Nachkommastelle auswerte würde ich alle 0,01m³ ein Impuls bekommen. Wieviel Impulse hast Du denn pro m³ Gas? Gruß Ingo
> musst mir dann mal sagen was Du dafür bekommst. Würde ich glatt > zuschlagen. Die Versandkosten von 2€. Würde es dann als Großbrief verschicken, dann muss ich nicht die Kabelage ablöten. > Für den Gas-/Stromzähler wollte ich die "intelligenz" in den SO-Bus > Controller hängen der über den CAN-Bus angebunden ist. Er soll die > Impulse zählen die in einer Minute eingegangen sind und dann daraus die > richtigen Werte Berechnen. Entweder aus den Impulsabständen und/oder der > Impulsanzahl innerhalb einer Minute. Ich speicher z.Z. die Impulse pro Minute. Der Zähler ist relativ gemütlich, auch im Winter, und wenn ich mich recht erinnere hatte ich kaum Werte über 10 gesehen. > Mein Gaszähler gibt nur alle 0,1m³ ein Impuls. Wenn ich allerdings die > "Spiegelfläche" auf der letzten Nachkommastelle auswerte würde ich alle > 0,01m³ ein Impuls bekommen. > > Wieviel Impulse hast Du denn pro m³ Gas? Ich habe an dem Gaszähler alle 0.01m³ einen Impuls. Die Auflösung der mechanischen Anzeige beträgt 0.001m³.
@Rudi: So mache ich es auch, nur eben dass das ganze dann per Ethernet im Minutentakt gepollt wird. Bei den Stromzaehlern ist es auch nicht viel anders: Grundlast auf der Phase wo der ganze Serverkram bei mir draufhängt sind auch gemütliche 10-12 Impulse pro Minute (1k / KWh)... Habe gerade eine andere Baustelle, Stromverbrauchsermittlung zentral an der Einspeisung. Die muss ich allerdings optisch machen, da dort 3x 150A Shunts mit extra Messwandler verbaut sind. Zum glück habe ich am Messwandler 2 rote LEDs für Wirkleistung und Blindleistung, beide mit 333,33 Imp/KWh (was für ne krumme Zahl ;). Die Erfassung mittels Phototransistor/100k Widerstand funktioniert problemlos. Ein weiterer Zähler für PV Einspeisung hat 2 grüne LEDs, eine mit 1k Imp und eine mit 10k Imp. Hierbei habe ich noch mit dem Wellenlängenbereich des Phototransistors zu kämpfen. grün liegt halt arg an der Grenze ;) Laborversuch mit 600k Widerstand anstatt 100k hat schon brauchbare Ergebnisse geliefert, allerdings darf es dann so gut wie kein "Fremdlicht" geben :-> BTW: sollten wir diesen Thread hier mal mit einem Fortsetzungsthread beenden? für meine Begriffe ist hier mittlerweile ganz schön viel Lesestoff angesammelt... Achja. Ich habe im Wiki den Ansatz mit dem "ServiceKey" Interface nur zu anfangs versucht zu dokumentieren, irgendwann bin ich bei dem Thema geistig ausgestiegen, wäre nett wenn sich jemand daran vergnügen könnte :) Gruss, Malte
@IngoF Bzgl. Impulsmessung von Gasuhr. Habe bei mir einen Actaris G4 RF1 verbaut. Ein normaler Reed-Kontakt tut. Allerdings keiner mit Gehäuse sondern ich musste das Glasrohr ganz hinten am Anschlag befestigen(bzw. hab vom Gehäuse den Deckel weg gemacht damit das Röhrchen direkt aufliegt). Es schaltet bei mir die vorletzte Ziffer wenn die 7 am Zählerfester sichtbar ist (die Mitte des Glasrörchens liegt bei mir also etwa zwischen der letzten und vorletzten Ziffer) Nur zur Info... Gruss Matthias
Hallo Matthias, Matthias schrieb: > Habe bei mir einen Actaris G4 RF1 verbaut. Ich habe das selbe Modell. Bei mir steht allerdings Schlumberger drauf. Der Zähler von Pipersberg hat auch das Schlumberglogo. Auf dem Impulsnehmer den ich kaufen wollte steht allerdings auch Actaris daruf. Scheint also alles das selbe zu sein. Matthias schrieb: > Ein normaler Reed-Kontakt tut. Habe von Conrad den billigsten und kleinsten Reedkontakt genommen (503770). Der zieht bei 15-35 AW an. Vermutlich ist der dann zu unempfindlich oder ich habe nicht genau die Position genau erwischt. Hatte auf der letzen und vorletzten stelle eigentlich alle Positionen ausprobiert. Aber zwischen den Zahlen hatte ich es noch nicht versucht. Laut dem gelinkten Impulsnehmer-PDF kann man gut sehen dass man das beste Ergebnis hat wenn man ganz hinten in der unteren Ecke den Kontakt anbringt. Habe aber das selbe Problem wie Du. Eben dass der Magnet in der vorletzten Zahl eingebaut ist. Auf dem Anzeigefeld steht auch 0,1Imp/m³ Also wird man genauere Ergebnisse nur mit der optischen Abtastung der letzten Stelle bekommen. Der Impulsnehmer gibt es für drei verschiedene Ziffern der Gasuhr. Also fü 1m³, 0,1m³ und 0,01m³. Laut Pipersberg funktioniert aber nur der Impulsnehmer der auch auf dem Anzeigefeld angegeben ist. Hatte es einfacher gefunden in alle drei Nachkommastellen einen Magnet einzubauen und man könnte sich aussuchen welche Genauigkeit man benötigt. Meiner Meinung nach hätten die der letzten Stelle drei oder vier Magnete spendieren können dass mann alle 0,00333m³ oder 0,0025m³ einen Impuls bekommt. Matthias schrieb: > (bzw. > hab vom Gehäuse den Deckel weg gemacht damit das Röhrchen direkt > aufliegt) Na dann will ich mal hoffen dass Du nicht den Deckel vom Gaszähler gemeint hast ;o) Gruß Ingo
Hallo Ingo das mit der Auflösung vom Zähler find ich auch doof, aber wenigstens ist überhaupt ein Magnet drin verbaut... Ich hab auch ewig probiert bis der Reed-Kontakt ansprach. Versuch mal die heizung zu stoppen wenn Ziffer 2 auf der 7 steht und teste dann. Mein Anfangsfehler war das ich die Mitte des Kontakts (überlappende Zungen) auf der 2. Ziffer positioniert habe, der Kontakt schaltet aber nur rechts oder links davon (hatte beste Empfindlichkeit bei mir mit externen Magneten getestet zwecks Einbauposition) Gruss Matthias
Hallo Matthias, ich werde mit den Reed-Kontakten nicht mehr herumexperimentieren. Habe jetzt eine gut funktionierende Lösung gefunden ;o) Rudi schrieb: > 34€ ist doch schon was ;-). Ich benutze den AN48820a. Ich kann dir in > etwa 2 Wochen meinen alten Sensor geben. Das Problem bei den Reed-Kontakten ist ja das das Magnedfeld durch den Kontakt muss damit der Kontakt schaltet. Habe auch bei meinen starken Pinwandmagneten nur ab und zu Kontakt wenn der Reed-Kontakt den Magnet direkt berührt, Am besten hat es am Rand des Magneten geklappt. Bei dem Hall-Sensor kann ich auch 15mm Platz lassen und ich bekomme noch einen guten Impuls. Wenn dann werde ich noch mal mit einer Reflexlichtschranke auf die 6 in der letzten Ziffer versuchen. Matthias schrieb: > Ziffer 2 auf der 7 steht Bei mir ist es bei der 6, das wird aber daran liegen dass mein Sensor fast an der Vorderkante liegt und nichtr wie Dir an der Hinterkante.
Matthias schrieb: > Ich hab auch ewig probiert bis der Reed-Kontakt ansprach. Was hast Du denn für einen Reedkontakt genommen? Was hat der denn für eine Ansprechschwelle? Bei Conrad habe ich noch einen gefunden der eine halb so große Ansprechschwelle hat (185026) und einen der sogar nur ein drittel davon braucht aber dann auch gleich über 8€ kostet (185067) Wenn Du den letzten mit 5-10AW hast erklärt sich auch warum Du ein Signal bekommst und ich nicht... meiner hat 15-35AW (503770)
Hallo Ingo, die Daten von meinem Reed-Kontakt weiß ich nicht. Der war mal von Pollin und ziemlich billig, kann also eigentlich nichts extra Tolles gewesen sein. Gruss Matthias
Hallo zusammen, dies ist mein erster Post in diesem Forum. Nachdem ich schon soviel hier gelernt habt, wird es Zeit mal was zurückzugeben... Mit den hier verfügbaren Infos habe ich eine KM271 mit folgenden Eigenschaften nachgebaut, die jetzt auch sehr stabil läuft. Eagle Schaltplan (mit lbr, die das KM271 Modul mit Platinenstecker als Bauteil definiert. Achtung, da fehlt noch das mechanische Sicherungsloch!) und SW für AVR644P und AVR Studio anbei. Der Schaltplan ist aktuell und funktioniert soweit klasse, das Board Layout muss noch angepasst werden (ich habe noch einiges am Prototypen hinterher "gepatched"). HW KM271 Schnittstelle hängt optogekoppelt an einem AVR644P zur Vorverarbeitung der Daten. Ziel war es, die Schnittstelle zur Heizung so wenig wie möglich zu beeinflussen, daher Opto-Kopplung und eigenes 3,3V Netzteil (gibt es für ein paar Euro in der Bucht) für den Digitalteil. Die Z-Doide am FG Fühlereingang ist nicht bestückt, sonst geht die Temperatur nicht unter 80°. Passenden NTC als FG Fühler gibt es bei Farnell, alle Spezialbauteile sind im Schaltplan mit Farnell Bestellnummern versehen, da gibt es auch Datenblätter... Digitalteil mit SD-Kartenanschluss (Speicherung der Daten als Backup, falls WLAN Verbindung ausfällt), FRAM (für non-volatile Daten, die man sehr oft schreiben muss, sehr schnell, keine Beschränkung der Schreibzyklen) und ConnectOne Nano WiReach WLAN Modul als Anbindung zum Netz. Alles über SPI verbunden (was für das Nano WiReach ein ganz schönes gefrickel ist...) SW Basierend auf FreeRTOS (ich weiss, es geht auch einfacher aber ich hatte den ganzen Setup schon von einem anderem Projekt). Von Interesse hier ist wohl insbesondere die Datei KM271Task.c, die den Treiber für das 3964 Protokoll enthält. Alle 10 Minuten werden die Temperaturdaten in eine Internet Datenbank gestellt (Langzeitspeicherung), Ereignisse werden im Minutentakt (falls nötig) in die Internetdatenbank gegeben. Die Auswertung erfolgt dann mit html/sql/php und Chart Tools auf Webseiten Basis (mach ich schon für andere Daten, siehe wetter.naehwerkstatt.de). Alle aktuellen Daten der Heizung sind im Webserver des Nano WiReach als Java-Script Variablen in Echtzeit verfügbar. Danke für eure ganzen Infos. Ohne die hätte ich meine Heizung (übrigens eine 2105, nicht 2107) nicht "anzapfen" können. Michael
Hallo Michael,
das Layout schaut etwas strange aus aber wenns funktioniert ok. Du sagst
du musstest an der Platine selbst noch etwas "patchen" hast du das im
Layout jetzt schon berücksichtigt?
Ich denk ich werde mir so was ähnliches für meine Heizungssteuerung
bauen, nur ohne die komplette Intelligenz auf dem Board. Gibts die
Optokoppler nur bei Farnell?
Grüße
Thomas
Hallo Thomas, stimmt, das Layout ist strange, ich habe einfach den Autorouter von Eagle benutzt und was da rauskommt ist nicht wirklich super. Zudem ist die Platine darauf ausgelegt bei mir in der Küche produzierbar zu sein, nicht um sie einem professionellen Leiterplattenhersteller zu liefern. Ist halt ein Bastel-Hobby Projekt, der Weg ist das Ziel... Wie gesagt, der Schaltplan ist aktuell und funktioniert so. Alle "Patches" sind da eingearbeitet, was dazu führt, das beim Board Verbindungen aufgelöst sind und einzelene Bauteile noch nicht plaziert sind. Ich hatte mir alles bei Farnell zusammengesucht, daher weiss ich nicht, ob es genau diesen Optokoppler auch woanders gibt. Dieser Typ hat den Vorteil, dass er 3,3V und 5V beherrscht. Da könnte man aber auch zwei unterschiedliche Typen für RX und TX einsetzen. Die SW ist natürlich auch nur ein Snapshot. Da geht es noch bei mir weiter. Allerdings funktinieren alle Blöcke schonmal sauber und das ist als Grundlage für andere besser als wenn das ein riesiges Sammelsurium wird. MfG Michael
Ach und mir ist gerade noch etwas aufgefallen: Der Schmitt Trigger hat doch 5V Supply. Wenn du da die 5V auf der TX Leitung hast gefällt das dem Logamatic Controller sicher nicht oder täusch ich mich da jetzt? P.S: Vielleicht setz ich mich später mal hin und route das mal von Hand. ;)
Hallo Thomas, nein, das sollte passen. Die Logamatic-Seite ist die 5V Seite. Der Digitalteil ist die 3,3V Seite. Der Schmitt-Trigger dient auf der Logamatic Seite hauptsächlich dazu, das TX von der Logamatic in Richtung Digital nur mit einem logischen Eingang zu belasten und ihm das Treiben der Optokoppler LED abzunehmen (was so 7mA ausmacht). MfG Michael
@Michael M. Das WLAN-Modul ist ja mal nett. Ich sehe du benutzt den teuren FRAM von Ramtron. Ich bin davon ab und benutze jetzt die 23K256 von Microchip. Die sind um Längen billiger wenn 32K ausreichend sind.
Hallo Rudi, danke für den Tipp! Werde ich mir mal anschauen! Ach, hier hab ich ein paar Bilder hinterlegt: http://wetter.naehwerkstatt.de/BilderHz/index.html Wie gesagt, schaut bloss nicht auf das Board, Küchenware mit händischer Durchkontaktierung. Mach ich aber schon seit Jahren so und reicht für meine Zwecke und Einzelstücke... MfG Michael
Ein paar Echtzeitdaten meiner Heizung sind online: http://wetter.naehwerkstatt.de/html/heizung.html Die Datenbankauswertungen werden wohl noch einige Wochenenden brauchen ;-) Michael
Hi Michael, das sieht ja schonmal top aus! Werde da etwas geringfuegig anpassen und eine ethernetvariante draus basteln... Vielen Dank für das Posting! Gruss, Malte
Angehängte Dateien:
-
avr-p28-sch.gif
26 KB -
377px-3mm5_jack_3_norm.svg.png
6,2 KB
Hallo, um die Funktion meiner Heizung zuvisualisieren versuche ich gerade die ServiceKey Schnittstelle nach zubauen. Bei der Menge an Informationen kein leichtes unterfangen ;-) Ich habe mir folgendes Atmega8 Entwicklungskit zugelegt, wie es Ingo F. wohl auch hat( http://www.olimex.com/dev/pdf/AVR/AVR-P28.pdf ). Bei diesem Board müssen noch die Pin's 2 & 3 vom Atmega mit dem MAX232 verbunden werden für die UART Funktion, was für den SK perfekt ist, da ja nur der TX Pfad über den D-Sub Stecker geht. RX wird ja an den 3,5 Klinkestecker des SK angeschlossen. Im Thread Buderus Bedieneinheit RC30 wird von folgender Pinbelegung gesprochen: >LINKS : GND >RECHTS: SIGNALOFFSET +12V, +-2.5V Signalpegel (etwa) >GND : +12V Wenn ich die Posts hier richtig verstanden habe, muss ich also "Rechts" und "GND" vom 3,5 Klinkestecker nehmen, um ein 2,5V Signalpegel für den RX Eingang vom Atmega8 zuhaben. Richtig? Kann man "Links" und "GND" zur Spannungsversorgung des Atmegas verwenden? Das Entwicklerkit hat am Pin 28 (PC5) eine LED, wenn ich mir die main.c von Rudi ansehe, liegt dort die LED auf dem PortC. Reicht es im Quelltext PORTB gegen PORTC und DDRB gegen DDRC auszutauschen? Muss ich sonst noch was im Quelltext anpassen (Taktfrequenz, etc.)? Oder beim Programmieren beachten (Bits die evtl. gesetzt werden müssen um den externen Quarz zuverwenden?). Vielen Dank schon mal für diesen Thread und die vielen Informationen! Gruß Kay
Angehängte Dateien:
-
fuses.png
25 KB
Hallo Kay, hatte ursprünglich auch ganz ohne Controller dazwischen ein Adapterkabel gebaut das die +12V und das Signal vom Klinkenstecker benötigt. Hatte nur +12V auf Pin 5 (GND) gelegt und das Signal auf RX vom 9 poligen Stecker. Allerdings sollte man dann darauf Achten dass man nicht irgendwie eine Masseverbindung zwischen Heizung und der Schaltung bekommt. Ich würde Dir empfehlen den RX-Pfad über einen Komperator machen der bei +12V schaltet. Das hätte den Vorteil dass Man die Schaltung auch am Bus betreiben kann und nicht unbedingt neben der Heizung bleiben muss. Den Schaltplan mit Dimensionierung für den RX-Pfad hatte ich ja schon gepostet Also über die 12V kann ich keine Aussage über die Belastung machen. Denke aber dass es direkt auf die 12V der MC10/BC10 geht. Also wenn es aus irgendwelchen Gründen einen Kurzen geben sollte hat die MC10/BC10 auch schön zu leiden. Soweit ich weiss reicht es einfach nur den Die Bits in den Registern zu entsprechend zu setzen. Das tauschen müsste aber auch gehen... Wenn überhaupt musst du die richtige Taktfrequenz eingeben und die Baudrate wird automatisch korrigiert. Soweit ich weiß habe ich den externen Quartz genommen. Habe mal das Hex-File und die Fuses aus dem AVR-Studio angehangen. Im Moment ist es so Das an Port C5 die LED nur so lange leuchtet wie Nutzdaten empfangen werden. Beim Polling nicht. Port C4 toggelt immer wenn die Schaltung eine Polling für 0x21 (Mischer) empfängt. Wenn kein Mischer vorhanden ist etwa alle 20-30 Sekunden. Mit vorhandenem Mischer etwa jede Sekunde. Auf Port B1 wird immer eine Antwort auf das Polling für den Mischer gesendet... Also am besten nichts an PortB1 anschließen... Bei mir habe ich die Schaltung mit dem Komperator verwendet müsste aber eventuelle auch mit dem MAX232 gehen. Gruß Ingo
Hallo Ingo, vielen Dank für deine Antwort und die Hex Datei. Ich muß leider gestehen, das ich noch einige Fragen habe, bevor ich den Lötkolben wieder anheize ;-) >Den Schaltplan mit Dimensionierung für den RX-Pfad hatte ich ja schon gepostet Ich habe leider nur die folgende Schaltung von dir gefunden (EMSlog.gif) mit RX & TX Pfad wobei ich den Eindruck hatte, das der TX Pfad noch in der Entwicklung ist ;-) Hast du schon Daten senden können? Ist die negative Spannung für den MAX232 notwendig? Bei meinem Olimex Board ist der MAX232 nur an die 5V angeschlossen. Da ich primär die Daten aufzeichnen möchte, hatte ich überlegt ob nicht auch ein Optokoppler aus reicht. Dafür wäre aber interressant wie stark man den Bus belasten kanm. 10-15 mA bräuchte man schon.... >Also über die 12V kann ich keine Aussage über die Belastung machen. >Denke aber dass es direkt auf die 12V der MC10/BC10 geht. Also wenn es >aus irgendwelchen Gründen einen Kurzen geben sollte hat die MC10/BC10 >auch schön zu leiden. Denke ein Kurzschluss sollte für den Bus kein Problem sein, da man den Klinkestecker am ServiceKey nicht ohne Kurzschluss einstecken kann ;-) Nur was der Bus dauerhaft verträgt ist noch offen. Wobei bei auf der Buderus HP zum orginal ServiceKey steht "Spannungsversorgung über angeschlosse- nes Regelgerät" -> Betriebsspannung 5-24 VDC (über Regelgerät) -> Leisungsaufnahme 5 VA Gruß Kay
Kay F. schrieb: > Ich habe leider nur die folgende Schaltung von dir gefunden (EMSlog.gif) > mit RX & TX Pfad wobei ich den Eindruck hatte, das der TX Pfad noch in > der Entwicklung ist ;-) Hast du schon Daten senden können? Sicher habe ich schon mal auf das Polling auf 0x21 geantwortet und es wurde auch in der RC30 angezeigt dass ein Mischer vorhanden ist. Aber der TX-Pfad ist wirklich noch in Bearbeitung. Wird jetzt wohl ganz anders aussehen. Mehr hatte ich noch nicht versucht.. Wollte erst mal eine vernünftige Sendeschaltung haben. Kay F. schrieb: > Denke ein Kurzschluss sollte für den Bus kein Problem sein, da man den > Klinkestecker am ServiceKey nicht ohne Kurzschluss einstecken kann ;-) Doch zumindest keinen Kurzschluss zwischen GND und 12 Volt. Kay F. schrieb: > "Spannungsversorgung über > angeschlosse- nes Regelgerät" -> Betriebsspannung 5-24 VDC (über > Regelgerät) -> Leisungsaufnahme 5 VA ALso das habe ich noch nciht gelesen. Dann müsste man ja die 12 Volt auch mit 5VA belasten können. Mit den Gleichrichter müsstest Du den SPannungsteiler aus R1 und R2 noch mal anpassen. Bei der Schaltschwelle muss an R2 2,5Volt liegen. Gruß Ingo Habe das noch nicht ausprobiert da ich parallel zur RC30 hänge und da keine +12 Volt habe Kay F. schrieb: > Ist die negative Spannung für den MAX232 notwendig? Bei meinem Olimex > Board ist der MAX232 nur an die 5V angeschlossen. Also die positive und negative Spannung am Maxim ist der Ausgang vom Spannungswandler. Hatte da mal einen OP angeschlossen der mindestens 5 Volt Symetrische Speisung brauchte. War aber nur testweise und keine gute Idee. Der LM393 kommt aber mit 5V Single-Supply aus. Die Berechnung der Widerstände war aber auf den Bus bezogen ohne den Brückengleichrichter bezogen.
Ups.. da sind wohl ein paar Abschnitte in meiner Antwort etwas durcheinander geraten.... Gruß Ingo
@Mario, Ingo: Könntet ihr (bzw. einer von euch beiden ;-) ) eine Protokollbeschreibung für das EMS-Protokoll zur Verfügung stellen? Etwas Code in irgendeiner Programmiersprache würde mir auch völlig reichen. Bislang habe ich leider nur Rudis (nicht kompletten) Python-Code gefunden. Mario schrieb weiter oben schon mal, dass er die relevanten Daten alle schon decodiert hat. Vielen Dank schonmal, Danny
Danny schrieb: > Könntet ihr (bzw. einer von euch beiden ;-) ) eine Protokollbeschreibung > für das EMS-Protokoll zur Verfügung stellen? Etwas Code in irgendeiner > Programmiersprache würde mir auch völlig reichen. Bislang habe ich > leider nur Rudis (nicht kompletten) Python-Code gefunden. Mario schrieb > weiter oben schon mal, dass er die relevanten Daten alle schon decodiert > hat. Inzwischen habe ich auch das Telegramm-XLS gefunden ;-) Sieht ja schon mal sehr gut aus, allerdings sind dann ja später noch ein paar Telegramme, z.B. von MM10 hinzugekommen...wenn also noch was aktuelleres existiert, wäre es schön, wenn das jemand posten könnte :) Danke, Danny
Hallo, ich habe jetzt mal meinen Quelltext durchwühlt und alles in einer Tabelle dokumentiert. Am besten alles vorherigen Dateien vergessen. Wenn noch jemand Werte hat die nicht aufgeführt sind bitte hier posten oder zumailen. Werde dann die Datei aktualisieren. Die PDF sollte iegentlich selbsterklärend sein. Die ersten Spalte Index ist eigentlich für andere nicht soooo wichtig. Das ist in meinem Programm der Index in dem Auswahlfeld. Die zweite Spalte Wert ist die Eindeutige ID für die Kurve in meiner SQL-Datenbank. Wie man sieht noch nicht so ganz aktualisiert. Beim Divisor bedeutet eine 0 gleich keine Berechnung (Digitalwerte). Bit ist das Bit in dem Wert. 0 bedeutet kein Digitalwert. Gruß Ingo
Hi, > ich habe jetzt mal meinen Quelltext durchwühlt und alles in einer > Tabelle dokumentiert. Am besten alles vorherigen Dateien vergessen. > > Wenn noch jemand Werte hat die nicht aufgeführt sind bitte hier posten > oder zumailen. Werde dann die Datei aktualisieren. Spitze, genau das, was ich gesucht habe - das nenne ich Service :) Ich werd dann mal die Reichelt-Bestellung für MAX232 usw. absetzen. Polling-Erkennung und Checksummen-Check soll dann in den Atmega8 mit rein, damit der sich nicht so langweilt ;-) Auswertung dann in 'nem Plug-Computer. Wenn ich fertig bin (kann noch ein Stück dauern ;-) ), poste ich Quellcode. Vielen Dank nochmal, Danny
Danny Baumann schrieb: >> Wenn noch jemand Werte hat die nicht aufgeführt sind bitte hier posten >> oder zumailen. Werde dann die Datei aktualisieren. > > Spitze, genau das, was ich gesucht habe - das nenne ich Service :) Das ist natürlich noch nicht alles. Falls jemand noch andere Werte hat gerne zumailen und werde dass dann aktualisieren... Gruß Ingo
IngoF schrieb: > Danny Baumann schrieb: >>> Wenn noch jemand Werte hat die nicht aufgeführt sind bitte hier posten >>> oder zumailen. Werde dann die Datei aktualisieren. >> >> Spitze, genau das, was ich gesucht habe - das nenne ich Service :) > > Das ist natürlich noch nicht alles. Falls jemand noch andere Werte hat > gerne zumailen und werde dass dann aktualisieren... Ich hab mal ein paar Fragen dazu ;-) - Deine Tabelle listet die Telegramme '10 00 3A' und '10 00 3D'. Hast du die bei dir schon mal gesehen oder wo kommt diese Information her? Ich sehe die nämlich bei meiner Heizung nicht, und ich habe hier im Thread auch keinen Verweis darauf gefunden...leider habe ich die gedämpfte Außentemperatur auch noch in keinem anderen Telegramm gefunden. - Byte 10 und 11 von '08 00 18' scheinen vertauscht zu sein Und noch als Info: Ich möchte wetten, dass die Bytes 9, 10, 11 und 15 in '10 00 3E' und '10 00 48' irgendwelche Solltemperaturen sind (HK1/Wasser/Kessel/HK2?) Im Tagbetrieb habe ich da die Werte 39/52/65/32 bzw. 26/33/40/27. Im Nachtbetrieb ist es 5/5/19/5 bzw. 5/5/7/5. Die Kombination 27/5 (d.h. 10 00 48, Byte 16) ist mit Sicherheit Soll HK2, weil das auch in '21 00 AB' vom Mischer kommt. Das ganze muss ich mal noch genauer prüfen. Danny
Angehängte Dateien:
-
rc30_reply1.png
2,2 KB -
rc30_reply_2.png
3 KB
Hallo Danny, Also die gedämpfte Außentemperatur habe ich igrendwann mal herausgefunden. Einige Telegramme kommen relativ selten und muss schon ziemlich lange warten. Das Telegramm ist in den Ergänzungen von Matthias zu meiner früheren Excel-Tabelle. [[Beitrag "Re: Logamatic 2107 Schnittstelle"]] Ist ziemlich weit oben aufgeführt. Er hatte allerdings das erste Byte nicht mitgeloggt. Ist ziemlich oben in der Tabelle. Dort ist auch das Telegramm 10 00 06 aufgeführt mit den der aktuellen Zeitinformation. Es gibt noch ein Byte was dort in diesem Telegramm nicht aufgeführt ist. Das Byte ist der Wochentag *0=Montag* bis *6=Sonntag* Teilweise hatte ich auch Werte die immer doppelt vorkamen und dann nur eine in meinem Quellcode verwendet. Kann sein dass bei einem anderen Heizungsausbau dort andere Werte angezeigt werden. Beim Flammenstrom ist das z.B. auch so es werden zweimal die selben Werte hintereinander im Telegramm gesendet. Vielleicht gibt es ja irgendwelche Heizungen die zwei Brenner haben und dann werden zwei verschiedene Werte angezeigt. Noch mal was zum generellen Telegrammaufbau: 1. Byte: Absenderadresse 2. Byte: Zieladresse 3. Byte: Telegrammart 4. bis (n-2). Byte: Daten (n-1). Byte: CRC Prüfsumme (n). Byte: Break (10 Bit lange "0") Die Quell und Zieladresse sind 7 Bit lang. Wenn bei der Zieladresse im Telegramm das Bit7 (8te Bit) gesetzt ist erwartet der Absender eine Antwort auf dieses Telegramm. Sonst gibt es nur noch das Pollingtelegramm. das nur aus einem Byte mit folgendem BREAK besteht. Dabei ist immer das Bit 8 gesetzt. Auf das Polling muss in bestimmter Zeit reagiert werden. Bei mir sendet die RC30 als erstes auf das Polling(0x90) erst mal seine Adresse (0x10) und sieht dann nach ob es gerade irgendwelche Daten zum senden hat und sendet dann das Break oder eben die Daten mit Prüfsumme und dann zum Abschluss das Break. Wer das Polling einmal bekommen hat kann so wie es aussieht soviel Telegramme schicken wie er will. Erst duch eine Antwort ohne Daten signalisiert er dass er nichts mehr zu senden hat. Wie anfangs vermutet wurde senden die Busteilnehmer nicht mit 15/10Volt auf den Bus. Sondern belasten den Bus nur mit etwa 40mA. Das macht eine Pegeländerung von 0,5 bis 1V. Jedes Empfangene Byte wird vom Busmaster wiederholt und es kann kontrolliert werden ob die Daten richtig verstanden wurden. Wenn man den Bus zu stark belastet (Einbruch auf knapp über 7 Volt (180mA??) sendet der Busmaster noch zusätzlich nach dem Break ein 0xFE. Vermute mal dass eine generelle Fehlermeldung ist. Vielleicht ist das auch eine Bestätigung dass die Prüfsumme vom Busmaster als fehlerhaft empfunden wurde. Ein Timeout das Rudi auf seinem Bus festgestellt hat konnte ich bisher kein einziges mal auf meinem Bus feststelle. Oder vielleicht meinte er das 0xFE Byte. Das bei mir bisher nur aufgetreten ist wenn ich den Bus gequält habe. Wäre mal abzuwarten bis ich mal testweise Telegramme mit fehlerhafter Prüfsumme auf den Bus gesendet habe. Werde Vermutlich eine Konstantstromquelle aus einem 08/15-Transistor und einem Emitterwiderstand von 82 oder 100 Ohm parallel zum Bus anklemmen. Das dürfte eine geschätze Belastung von 40-45 mA geben. Habe mal ein Screenshot von meinem DSO angehangen. Dort kann man gut das Sendesignal mit Echo erkennen. Die RC30 lässt sich bei diesm Telegramm 100ms Zeit bis es die Daten sendet. Das kann man ganz gut am ersten Bild sehen. Beide Bilder stammen aus dem selben Oszillogramm. Oben ist das ganze Signal blau hinterlegt. Der schwarze Bereich ist darunter vergrößert dargestellt. Gruß Ingo Edit: falls sich jemand fragt was die rote Linie ist.... Das ist die zweite Port-LED aus meiner letzten geposteten HEX-Datei für das Experimentierboard. Die LED fängt nach dem zweiten Byte an zu leuchten und erlischt zwei Bytes nach dem Break.
Angehängte Dateien:
-
RC30.png
3 KB
Habe noch ein Sceenshot mit einem von der RC30 gesendeten Byte gefunden.... Wie man sieht ist die Pegeländerung zwischen High und Low nur 360mV. Bei meiner Sendeschaltung wurde das Signal aber erst mit etwa 35mA Last verstanden das war irgendwas zwischen 0,5 und 1,0V. Gruß Ingo
@Ingo: > Sonst gibt es nur noch das Pollingtelegramm. das nur aus einem Byte mit > folgendem BREAK besteht. Dabei ist immer das Bit 8 gesetzt. Bei mir wird bei der 0x89 z.B. kein Break gesendet. Ich hatte damals extra mit dem Oszi. danach gesucht. Aus diesem Grund habe ich oft Pollingtelegramme wie 0x89 0x90 die natürlich so nicht stimmen und ein Timeout eingebaut.
Ach stimmt... kann mich noch schwach dran erinnern... Hattest ja mal dieses Log mit den ganzen FF's. Allerdings habe ich bei mir noch kein einziges Polling/Telegramm gefunden dass ohne Break gesendet wurde. Also nehme ich mal an dass das nicht vorgesehen ist. Vielleicht ein Softwarefehler oder Übertragungsfehler. Oder ich habe einfach nicht gründlich gesucht.. Will das ja auch nicht ausschließen... Wie sieht denn Dein EMS-Bus aus? Bei mir liegt das Kabel alleine in einem Extra Rohr zum Wohnzimmer und ist ein ganz normales 08/15 ungeschirmtes etwa 0,7mm² Durchmesser. Bis auf meine mitlauschende Schaltung direkt an der RC30 habe ich nichts angeschlossen. Aber die 0x89 oder 0x90 werdem ja vom Busmaster geschickt und könnten dann ja nicht verschluckt werden, oder? Gruß Ingo
> Wie sieht denn Dein EMS-Bus aus? Alles direkt in der Heizung bis auf den Logger (~50cm ungeschirmt an der Klinke). > Aber die > 0x89 oder 0x90 werdem ja vom Busmaster geschickt und könnten dann ja > nicht verschluckt werden, oder? Nach der 0x89 kommt einfach nichts. Es ist kein sporadischer Timeout sondern immer auf einer Adresse. Die BC10 (Addr. 0x09) scheint da nicht zu antworten. Evtl. weil sie schon angemeldet ist. Man kann hier nur Vermutungen anstellen.
Hi, > Also die gedämpfte Außentemperatur habe ich igrendwann mal > herausgefunden. Einige Telegramme kommen relativ selten und muss schon > ziemlich lange warten. Hab sie inzwischen gefunden ;-) '0x10 0x00 0xa3 0x00 0x0d 0x11 0x01' Byte 5 ist die gedämpfte Außentemperatur Byte 6 + 7 sind mit Sicherheit irgendwelche Flags (beim Wechsel Tag->Nacht gehen die auf 0x00 0x00) Und noch ein paar mehr Infos: '0x10 0x00 0x3e 0x00 0x04 0x02 0x28 0x00 0xd4 0x00 0x00 0x27 0x34 0x41 0x00 0x00 0x00 0x11 0x22' Byte 7 ist die Raum-Solltemperatur (durch 2 dividieren) Byte 8 + 9 sind die Raum-Isttemperatur (durch 10 dividieren) Bytes 12 - 14 sind die Heizkurve für HK1 (Byte 12 = Solltemp. bei 10°C, Byte 13 dito für 0°C, Byte 14 dito für -10°C Byte 18 sind irgendwelche Flags, wahrscheinlich Pumpe HK1 Byte 19 ist die Solltemperatur Vorlauf HK1 '0x10 0x00 0x48 0x00 0x04 0x02 0x28 0x00 0xd4 0x00 0x00 0x1a 0x21 0x28 0x00 0x00 0x00 0x11 0x17' ist exakt das gleiche für HK2 Der einzige Wert, der mir jetzt noch fehlt, ist der Servicecode ;-) > Dort ist auch das Telegramm 10 00 06 aufgeführt mit den der aktuellen > Zeitinformation. Es gibt noch ein Byte was dort in diesem Telegramm > nicht aufgeführt ist. Das Byte ist der Wochentag *0=Montag* bis > *6=Sonntag* Ist das Byte 11? Sieht zumindest so aus... > Wie anfangs vermutet wurde senden die Busteilnehmer nicht mit > 15/10Volt auf den Bus. Sondern belasten den Bus nur mit etwa 40mA. Das > macht eine Pegeländerung von 0,5 bis 1V. Jedes Empfangene Byte wird vom > Busmaster wiederholt und es kann kontrolliert werden ob die Daten > richtig verstanden wurden. Sicher, dass das nur über die Belastung gemacht wird? Meinen EMS-auf-UART-Konverter (basierend auf deiner Schaltung) betreibe ich bus-powered, und der zieht um die 30mA. Das scheint den Bus aber nicht zu stören, d.h. die Busteilnehmer detektieren nicht den Spannungslevel, sondern Differenzen? Danny
Danny Baumann schrieb: > Der einzige Wert, der mir jetzt noch fehlt, ist der Servicecode ;-) ... und der steht in '08 00 18' an Stelle 23 und 24 (z.B. 0x30 0x59 = '0Y').
Danny Baumann schrieb: > Und noch ein paar mehr Infos: > '0x10 0x00 0x3e 0x00 0x04 0x02 0x28 0x00 0xd4 0x00 0x00 0x27 0x34 0x41 > 0x00 0x00 0x00 0x11 0x22' > Byte 7 ist die Raum-Solltemperatur (durch 2 dividieren) > Byte 8 + 9 sind die Raum-Isttemperatur (durch 10 dividieren) > Bytes 12 - 14 sind die Heizkurve für HK1 (Byte 12 = Solltemp. bei 10°C, > Byte 13 dito für 0°C, Byte 14 dito für -10°C > Byte 18 sind irgendwelche Flags, wahrscheinlich Pumpe HK1 > Byte 19 ist die Solltemperatur Vorlauf HK1 Ups.. die habe ich im Quelltext wohl übersehen... Die werden bei mir eigentlich auch mitgeloggt. Nur die -10/0/10°C Werte sind mir neu. Danny Baumann schrieb: > Ist das Byte 11? Sieht zumindest so aus... Wird wohl so sein. ist das einzige Byte was in der Ergänztung von Matthias nicht aufgeführt wurde bei dem Telegramm.... Danny Baumann schrieb: >> Also die gedämpfte Außentemperatur habe ich igrendwann mal >> herausgefunden. Einige Telegramme kommen relativ selten und muss schon >> ziemlich lange warten. > > Hab sie inzwischen gefunden ;-) Ups.. war mir auch sicher dass ich die dokumentiert hatte... Hatte das von Dir auch falsch verstanden. Danny Baumann schrieb: > Sicher, dass das nur über die Belastung gemacht wird? Keine Ahnung wie das in der RC30 gemacht wird. Aber wenn ich das Signal über eine 40mA Stromsenke erzeugt habe sah das Signal genauso wie aus dern RC30 aus, nur dass es etwas mehr Amplitude hat. Deine Schaltung belastet den Buss ja gleichmßig und bewirkt daher keine Spannungsschwankungen. Hast auch garantiert einen entsprechenden Bufferkondensator eingebaut, oder? Danny Baumann schrieb: > Das scheint den Bus aber nicht > zu stören, d.h. die Busteilnehmer detektieren nicht den Spannungslevel, > sondern Differenzen? das meinte ich ja damit.. vielleicht auch nur ungünstig von mir ausgedrückt. Duch diese Belastung habe ich die Spannungsschwankungen erreicht...
Ingo F. schrieb: > Ups.. die habe ich im Quelltext wohl übersehen... Die werden bei mir > eigentlich auch mitgeloggt. Nur die -10/0/10°C Werte sind mir neu. Die -10/0/10 ist das, was RC30 bei mir zu den entsprechenden Werten anzeigt. Es sagt sowas wie 39 52 65 10 / 0 /-10 HK1 (das ganze im Servicemenü -> Heizkennlinie) > Deine Schaltung belastet den Buss ja gleichmßig und bewirkt daher keine > Spannungsschwankungen. Hast auch garantiert einen entsprechenden > Bufferkondensator eingebaut, oder? Ich hab 10µF eingebaut, ich bin mir aber nicht sicher, ob das "entsprechend" ist. Für 400mV Spannungshub für die Dauer von ein paar ms sollte es evtl. reichen ;-) Danny
Na ich meinte ja damit es eine gleichmäßige Belastung ist und keine Spannungsschwankungen hervorruft... Für die Sendeschaltung soll ja gerade nicht den Strom aus dem Kondensator saugen.. Das wäre dann ja Sinnlos..
IngoF schrieb: > Na ich meinte ja damit es eine gleichmäßige Belastung ist und keine > Spannungsschwankungen hervorruft... Für die Sendeschaltung soll ja > gerade nicht den Strom aus dem Kondensator saugen.. Das wäre dann ja > Sinnlos.. Ähm, ich habe bei mir keine Sendeschaltung verbaut...nur Atmega8 + MAX232 + OPV für den RX-Pfad. Stromversorgung via 78L05. Senden war mir dann doch zu heikel ;-)
Danny Baumann schrieb: > Hab sie inzwischen gefunden ;-) > '0x10 0x00 0xa3 0x00 0x0d 0x11 0x01' Ups.. hatte ich dokumentiert.. Allerdings hatte ich einen Zahlendreher und habe 3A statt A3 geschrieben. So wie es aussieht sind wohl alle meine Byteangaben einen zu hoch.. Muss das noch mal nachsehen...
Danny Baumann schrieb: > Senden war mir dann doch zu heikel ;-) Also bisher habe ich bis auf eine Simple Polling-Antwort auch noch nichts gesendet. Wusste ja nicht dass das Echo sein muss und kein Fehler ist. Werde mich da mal in der nächsten Zeit ein wenig dran versuchen wenn ich die neue Software mit CAN fertig habe. Habe mal meine Tabelle aktualisiert und angehangen. Hatte bei 0 angefangen zu zählen und die beiden Framing-Bytes die der Atmega einfügt auch mitgezählt. Dadur hatte ich überall einen zuviel. Das 3A Telegramm war das A3 Telegramm ;o) Das 11.Byte war also richtig mit dem Wochentag. Den Service-Code habe ich auch bei mir gefunden Gruß Ingo
Die Versionen der Module wäre mal nicht schlecht. Evlt. sind wir genug und können die Nachrichten vergleichen ? Anbei nochmal meine Versionen. Es lohnt sich nur wenn die Versionen unterschiedlich sind: UBA3/MC10 (Universeller Brennerautomat/Mastercontroller) - 8 - V3.02 BC10 (Basiscontroller) - 9 - V2.02 RC30 (Raumcontroller) - 16 - V2.08 Version 3 KIM (Kesselidentifikationsmodul) 1051
Ich habe UBA3/MC10 - 2.05 BC10 - 2.00 RC30 - 2.05 Version 9 / KIM-Nummer 1006 Rudis Anlage ist offensichtlich neuer als meine (Ende 2004) ;-)
Ich habe UBA3/MC10 - 2.03 BC10 - 2.00 RC30 - 2.05 Version 12 / KIM-Nummer 1003 Danny Baumann schrieb: > Rudis Anlage ist offensichtlich neuer als meine (Ende 2004) ;-) Meine kommt ja dann fast aus der Steinzeit ;o)
Hallo, ich lese aus Interesse etwas mit und da ich eine nun eine MC10, BC10 und RC35 erworben habe, um meine alte Steuerung zu ersetzen, bin ich sehr gespannt, wie sich das hier entwickelt. Mir ist noch nicht klar, welche Schnittstellenhardware geeignet ist aber ich verfolge den Thread weiter. Bisher habe ich nur einige Erfahrungen mit AVR-NET-IO und dem AVR Webmodul von Radig. Schön wäre es, wenn ich die Daten nicht nur lesen (was schon ein Fortschritt wäre), sondern auch senden könnte. Ich nutze die Software IP-Symcon zur Hausautomation. Tolle Arbeit Jungs. Danke
Ihr könnt ja mal schauen ob die Werte stimmen. Index 4 in den Typ 0x02 Nachrichten ist wohl die Identifikation der Module. UBA3/MC10 (Universeller Brennerautomat/Mastercontroller) - 8 - V3.02
1 | 08 10 02 00 40 03 02 3d |
2 | VH VL |
3 | VH VL - Version |
BC10 (Basiscontroller) - 9 - V2.02
1 | 09 10 02 00 44 02 02 6f |
2 | VH VL |
3 | |
4 | VH VL - Version |
RC30 (Raumcontroller) - 16 - V2.08
1 | 10 00 02 00 43 02 08 5d |
2 | VH VL |
3 | |
4 | VH VL - Version |
Version 3 KIM (Kesselidentifikationsmodul) 1051
1 | 08 10 04 00 04 1b 03 40 18 19 30 00 00 69 6b 0c 5d |
2 | KH KL VV |
3 | |
4 | KH KL - KIM |
5 | VV - Version |
Angehängte Dateien:
Hallo Leute, habe mir im Mai eine Buderus GB162-25 T40S zugelegt mit: UBA3.5 - 3.06 RC 35 - 1.11 KIM 1076 und möchte natürlich auch den EMS-Bus anzapfen - zum Lesen. Deshalb verfolge ich Euren Thread schon seit einigen Monaten, ist aber nicht einfacher für mich geworden :-*). Was das Bus-Interface betrifft, geht es mir ähnlich wie meinem Vorredner/Schreiber. Man/ich weiss eigentlich nie so genau, was der neueste Stand ist. Versteht das bitte nicht als Kritik! Ich denke nur, dass es hier eine Vielzahl von stillen Mitlesern gibt, denen es ähnlich geht. Und ich finde es schade, dass Eure tollen Erkenntnisse im "Nebel" des Threads unterzugehen drohen. Deshalb meine Bitte an Euch: Alle ein bis zwei Monate Eure neuesten Ergebnisse als Schaltplan, Code, etc. anhängen. Ja, ich weiss, es ist zusätzliche Arbeit, aber nach meinem Geschmack würde sich der Überblick über den Thread deutlich erhöhen. In der Hoffnung, keine Fehlbitte geäussert zu haben, bin ich auf die weiteren Erkenntnisse gespannt - und hoffe in nicht all zu ferner Zukunft mit meinen eigenen Ergebnissen weiteres Licht ins Dunkel des EMS-Bus zu bringen ;-). --- Eigentlich gehört es vom Thema nicht hierher, aber weiter oben war schon mal vom Auslesen des Gaszählerstandes die Rede. Deshalb hier mal meine eigenen Erfahrungen, vielleicht interessiert es jemanden. Habe hier einen Elster/Kromschröder Gaszähler BK4. Der hat in der letzten Zählerrolle (1 Ltr.) einen Magneten bei der Ziffer 9. Also kann man die 0,01 cbm (10 Ltr.) zuverlässig bestimen. Als Reedkontakt habe ich bei Frau R. einen MK 1471B um 2,55 Euronen bestellt. Der passt prima in ein 3cm-Stück Schutzhülle für DIL-ICs. Darum 3 Lagen Panzerband gewickelt und das Sandwich passt haargenau in die Zähleraussparung. Und weil sich das Sandwich echt easy Ein- und Ausstecken lässt, ist auch sichergestellt, dass bei einem Zählerwechsel nicht ein neuer Reedkontakt beschafft werden muss. Also kann der Gasmann ruhig 2 mal klingeln ;-). Das Zählen übernimmt bei mir ein DS2423, also ein 1-Wire Counter. In diesem Chip sind aber zwei 32-bit Zähler integriert, so dass noch ein Zähler frei war. Der zählt jetzt das Kondenswasser über einen Regenmesser. Habe ich auch bei Frau R. bestellt. Kostet ca. 25 Euronen und nennt sich WS 73003. - Und nein, ich bekomme keine Tandieme von R.! - Das Teil besteht aus dem eigentlichen Regensammler für den Garten und einer Auswertestation fürs Haus, verbunden per Funk. Die Auswertestation steht jetzt auf meinem Schreibtisch und zeigt mir Temperatur, Datum und Uhrzeit; für die Applikation habe ich sie nicht benötigt. Was zum Einsatz gekommen ist, ist der Regensammler. Jepp, die Dinger funktionieren mit einer Wippe ------|------ , das Wasser kommt gedrosselt von oben, wenn die linke oder rechte "Schaufel" voll ist, kippt die Wippe. Der Mengeninhalt der "Schippe" ist bekannt, ein in der Wippe befestigter Magnet steuert den Reedkontakt. Für einen Liter kippt die Wippe 210 mal. Das gibt eine relativ gute Genauigkeit, Meteorologen haben eben hohe Ansprüche. Also Batterien raus, damit die Kiste nicht funkt und auf der Platine direkt an den Reedkontakt, bzw. an zwei Leiterbahnen, die lötfreundlich in einem Pad enden. Diesen Reedkontakt habe ich mit dem zweiten Zähler verbunden, so dass ich jetzt synchron Gasverbrauch und Kondenswasseranfall zähle. Das hat den Vorteil, dass ich über diese beiden Parameter den Netto-Abgasverlust meiner Heizungsanlage bestimmen kann. Da gibt es einen schlauen Doktor an der Uni des Saarlandes, der hat in einer Patentschrift vorgerechnet, dass der Netto-Abgasverlust (qA) von Gas-Brennwertgeräten (GBWG) sich wie folgt bestimmen lässt: qA=( 1,6 * G – W )/( 1,6 * G ) * 13,5 [%] oder vereinfacht: qA = ( 1 – W /( 1,6 * G) ) * 13,5 [%] wobei: qA = Netto-Abgasverlust in % W = Kondenswasser in Liter G = Gas in cbm (m³) Wen die Herleitung interessiert 8-/, der wird hier fündig: http://www.uni-saarland.de/fak7/fze/KFA.htm Achso, die Auswertung der Zähler und weiterer 1-Wire Bauteile erfolgt in meinem FLI4L mit Opt-OW. O.k. - ist ein bisschen lang geworden, hoffe Ihr seid nicht ermüdet und forscht weiter ;-). Schönen Sonntag noch und Gruß Karl M.
Hallo Rudi, konnte leider nur die KIM-Version in den Telegrammen finden. Da Du ja eine ganze Version bei Deiner RC30/35 weiter bist kann es durchaus sein dass die Telegramme anders abgefragt werden. Habe Dir mal meine ganzes Log angehangen. Irgendwo müssen die ja versteckt sein. Allerdings wohl nicht ganz so einfach im BCD Format wie in Deinen Telegrammen. Konnte sie jednfalls nicht finden. Gruß Ingo
IngoF schrieb: > Habe Dir mal meine ganzes Log angehangen. Etwas unglücklich formuliert... Habe sie in der Mail an Dich angehangen. Müsste schon angekommen sein. Gruß Ingo
Hallo, ich habe nur meine alte 3220 Steuerung ersetzt und reiche mal die Versionsdaten nach: RC 35 V1.06 MC 10 V2.07 BC 10 V2.03 SAFe V5.20 BIM V1 BIM Nummer 7000 Gruß Andy
Rudi schrieb: > @Andreas F. > > Wie lauten die Busadressen von deiner Anlage ? Ich habe leider noch keinen Zugriff auf den Bus (siehe Beitrag "Re: Logamatic 2107 Schnittstelle" ), denn mir fehlt noch die passende Schnittstellenschaltung. Ich warte noch auf Euch. ;-) Ne andere Möglichkeit, diese anzuzeigen, kenne ich nicht. Gruß Andreas
Andreas F. schrieb: > Ne andere Möglichkeit, diese anzuzeigen, kenne ich nicht. Ist auch im "Sondermenü" zu finden. Unter "Monitordaten" und dann "Bus-Status". Gruß Ingo
IngoF schrieb: > Ist auch im "Sondermenü" zu finden. > Unter "Monitordaten" und dann "Bus-Status". gefunden unter Diagnose/Monitorwert/Busteilnehmer MC 10/SAFe Adr. 8 BC 10 Adr. 9 RC 35 Adr. 16 Gruß Andreas
Rudi schrieb: > hat dein SAFe keine Adresse Hallo Rudi, wenn ich dass richtig verstanden habe ist dass das selbe wie UBA3. Keine Ahnung wodrin der Unterschied ist. Vielleicht auch nur der Vorgänger der UBA3 Gruß Ingo
IngoF schrieb: > wenn ich dass richtig verstanden habe ist dass das selbe wie UBA3. Keine > Ahnung wodrin der Unterschied ist. > Vielleicht auch nur der Vorgänger der UBA3 Ich bin kein Heizungsbauer, aber das BRM 10 ist doch, wenn ich das richtig verstehe, kein richtiger SAFe. Es ist eine Schnittstelle, um ältere oder andere Brenner an einer EMS-Regelung zu betreiben und SAFe wohl nachzuahmen. Gibt es erst seit 2007. Alle Möglichkeiten hat man damit wohl nicht. Meine Angaben stehen genau so wie angegeben im Display. Gruß
Hallo, Ich hab gemäß dem Thread und den beiden Schaltungsvorschlägen Rx und Tx am Modulsteckplatz für KM271 abgegriffen, UART auf 2400bd stehen, bekomme aber keine Antwort (auch kein STX) von der 2107. Nun die Frage: Muss man damit überhaupt die RS232 aktiviert wird noch Bauteile für den FG bestücken? Wenn ja welche? oder muss/kann das Modul in der Steuerung aktiviert werden. vielen Dank für eure Super Arbeit und viele Grüße jens
ok, der 10k R zwischen 5 und 7 scheint zu reichen, nun ist Abgas einstellbar und das Modul wohl erkannt. Aber Daten bekomm ich trotzdem noch keine ... Hat jemand noch eine Idee? vg jens
tx und rx vertauscht ... :-) schon immer mein Problem. Obwohl ich es an sich schon 10mal gecheckt hatte. nun werd ich mal weiter sehen was so an Daten kommt. vg und noch mal Danke für alle Infos im Forum und wiki jens
Hallo, ich habe noch mal ein wenig am Bus herumgespielt und stumpf ein paar Pollings beantwortet und darauf gewartet was meine RC30 anzeigt. 0x08 = MC10 0x09 = BC10 0x10 = RC30/35 0x11 = Hydr. Weiche 0x12 = ZM EED 0x13 = Gerät (4x) 0x17 = RC20 Heizkreis 0x18... = RC20 (8x) 0x20... = Mischer (8x) 0x28... = Warmwasser (8x) 0x30... = Solar (8x) 0x38... = Gerät (40x) Laut meinem Pollingmitschnitt scheinen Adressen über 0x60 nicht gepollt zu werden. Ausnahmen scheinen 0x61 und 0x68 zu sein. Habe auch nicht alle Adressen überprüft und teilweise nur stichprobenartig meine Tabelle überprüft. Ist ja fast alles selbsterklären. Gerät ist wohl so eine Art Platzhalter für irgendwelche Module die der RC30 noch nicht bekannt waren. Oder Busteilnehmer wie Fernwirkmodem, ServiceKey, RS232-Gateway, .... Also wer sowas haben sollte bitte einfach mal nachsehen und mir irgendwie eine Info zukommen lassen. Bin von Natur aus neugierig ;o) Muss ja nicht im Forum sein... Aber was zum Teufel ist "ZM EED"??? ZM = ZentralModul oder ZusatzModul? Was soll denn EED sein? Hat jemand irgend eine Idee? Gruß Ingo
Ingo F. schrieb: > Aber was zum Teufel ist "ZM EED"??? ZM = ZentralModul oder ZusatzModul? > Was soll denn EED sein? Hat jemand irgend eine Idee? Bei Buderus bedeutet ZM einfach Zusatzmodul. Aber EED !? Wie sieht deine jetzige Sendestufe mit dem Transistor aus ? Ich will mir demnächst eine neue Platine mit Opto. usw. bauen. Grüße.
Rudi schrieb: > Bei Buderus bedeutet ZM einfach Zusatzmodul. Aber EED !? Servus Leute! EED ist ein "Externe Störungsanzeige (EED)"-Modul. Info z.B.: http://www.buderus.it/media/prodotti/1-murali/1_6-regolazioni/istruz_tecniche/_RTG_IstrUso_EED_705067A_08_06.pdf HTH Karl M.
Rudi schrieb: > Wie sieht deine jetzige Sendestufe mit dem Transistor aus ? Ich will mir > demnächst eine neue Platine mit Opto. usw. bauen. Also sie wird sehr wahrscheinlich einfach nur ein 82 oder 100 Ohm Emitterwiderstand für die Stromregelung haben und mit dem Basis am PIC/Atmega8 hängen. Dann sollte der Strom passen. Die Busadressen habe ich noch mit der "alten" Schaltung ermittelt. Bin dabei die Software noch mal neu zu schreiben. Wenn das fertig ist mach ich mit der Sendeschaltung weiter... Hinter soll es möglich sein per Jumper aus mehreren Seriellen Protokollen auszuwählen. 1) EMS (EMS-Bus) 2) 3964R 3) ASCII HEX-codiert 4) das bisherige Format mit AA 55 gerahmt 5) nur geänderte Werte 6) ..... mal sehen wieviel es wirklich werden. Die ersten beiden auf jeden Fall. 3964R verwendet ja Buderus für die Fernwirkmodems. Vielleicht ja auch für den ServiceKey und RS232-Gateway. Das mit dem AA 55 Rahmen fand ich nicht ganz sooo gut. rein theoretisch wäre es ja möglich dass die Werte AA 55 irgendwann mal in den Daten vorkommen. Bei 3964R kann das ja nicht passieren. Gruß Ingo
Karl M. schrieb: > EED ist ein "Externe Störungsanzeige (EED)"-Modul. Danke... Also die Abkürzung von: Zusatzmodul External Error Detection :o) Hätten sich ja auch für eine Sprache entscheiden können... Na dann kann ich die Adresse ja schon mal vergessen. Der Gateway oder Service-Key muss dann wohl eines von den "Geräten" sein. Dann muss es ja ein ähnliche externe Fehleranzeige auch (irgendwann) für den EMS-Bus geben. Die ist vermutlich für das 4000er Bussystem?
Ingo F. schrieb: > 3964R verwendet ja Buderus für die Fernwirkmodems. Vielleicht ja auch > für den ServiceKey und RS232-Gateway. Ja, zumindestens der Service-Key arbeitet damit. Ingo F. schrieb: > Das mit dem AA 55 Rahmen fand ich > nicht ganz sooo gut. rein theoretisch wäre es ja möglich dass die Werte > AA 55 irgendwann mal in den Daten vorkommen. ;-). Es ging mir damals eher darum, den Anfang und das Frameende zu markieren. Durch die Längenangabe würde es auch bei doppelten AA 55 funktionieren. Ich lese z.Z. die Daten über die UART mit einem 50MHz Cortex. Die CRC-Berechnung und das Parsen der Werte sind relativ CPU-Lastig. Die CPU muss auch noch andere Dinge erledigen (Loggen/SD-Karte, Netzwerk, CAN-Master). Ich werde hauptsächlich aus diesem und anderen Gründen einen 72MHz STM für die Parsergeschichte einsetzen. Der Platzbedarf auf der Platine ist durch die integrierte CAN-Hardware auch noch kleiner im Vergleich zu einem ATMEGA323P. Der STM kann dann den Stream parsen und bei Änderungen auf dem CAN-Bus brüllen. Grüße.
Nachtrag: Evtl. hat ja jemand Lust und Laune und kann für die CRC Berechnung die Tabelle, für eine Tabellen basierte CRC, erstellen. Das sollte dann noch einiges an CPU-Zeit sparen, wenn genug Speicher vorhanden ist. Grüße.
Rudi schrieb: > Evtl. hat ja jemand Lust und Laune und kann für die CRC Berechnung die > Tabelle, für eine Tabellen basierte CRC, erstellen. Hallo Rudi, Das wird leider nicht gehen. Die EMS-Prüfsumme ist ja kein wirkliches CRC mit Generatorpolynom. Es ist ja nur ein XOR mit verschiebung und ein paar Bits setzen wenn der bisherige Wert einen bestimmten Wert überschritten hat. Also nichts was man mit Tabelle machen könnte, oder? Bei der CRC mit Generatorpolynom wird die CRC ja immer Bitweise "errechnet". Durch die Tabelle erspart man sich dann acht Schritte und hat dann ein Byte was man XORen kann, oder? Die EMS-Prüfsumme ist ja schon auf Byte ebene und wird nicht für jedes Bit errechnet. Allerdings habe ich auch im Moment keine Ahnung wie die Tabelle bei einer CRC mit Generatorpolynom wirklich erstellt wird und angewendet wird. Habe nur mal am Rande davon irgendwas mitbekommen. Vielleicht geht es mit ein wenig Gehirnschmalz ja doch... Gruß Ingo
Rudi schrieb: > Ich lese z.Z. die Daten über die UART mit einem 50MHz Cortex. Die > CRC-Berechnung und das Parsen der Werte sind relativ CPU-Lastig. Wie sieht denn das Parsen bei Dir aus? Machst Du wie bei Deiner MySQL einen "String" raus, der komprimiert wird? Ich hatte vor einfach wie bei meiner SQL einfach einen 16Bit-Wert daraus zu machen und eine ID mitzusenden. Je nach dem welches Frame ankommte wird nur ein entprechendes Unterprogramm ausgeführt. Die Werte werden im Buffer zwischengespeichert (z.B. ID*3+Bufferanfang). Bei änderungen wird der Wert übertragen. 2*8Bit +8Bit für einen primitiven Zeitstempel. Das klingt eigentlich so als ob dass parrallel mit dem Empfang mitlaufen könnte. Allerdings macht meine CPU nichts anderes als empfangen und weiterleiten und dann auch irgendwann mal die Werte auslesen.
Ingo F. schrieb: > Wie sieht denn das Parsen bei Dir aus? Machst Du wie bei Deiner MySQL > einen "String" raus, der komprimiert wird? Schon lange nicht mehr. Ich habe in der DB die eigentlichen Werte als Float gespeichert und den Rest als Integer (ID/Timestamp). Das bringt etwas mehr Performance. Leider kann mysql noch keinen Timestamp mit Millisekunden, da gibt es aber ein Workaround, falls man diese Auflösung benötigt. Aus Performance-Gründen tendiere ich eher dazu, für jeden Sensorwert eine eigene Tabelle anzulegen. Ich habe es aber noch nicht getestet. > Ich hatte vor einfach wie bei meiner SQL einfach einen 16Bit-Wert daraus > zu machen und eine ID mitzusenden. Je nach dem welches Frame ankommte > wird nur ein entprechendes Unterprogramm ausgeführt. Ja, so in etwa mache ich es jetzt auch. Frame empfangen, CRC prüfen und je nach Absender an die entsprechende Unterfunktion übergeben. Dann parsen und ab hier wird jeder Wert als Sensor gesehen und entsprechend weiterverarbeitet. Also wenn ich von der Buderus zwei Temperaturen bekomme sind das nach dem Parsen einfach 2 Sensoren die die Temperatur messen. Das ist erstmal mein Ansatz für die Handhabung der einzelnen Daten. Ich versuche alles in ein Schema F zu bekommen, je nach Sensor verallgemeinern, damit ich später bei einer zusätzlichen Regelung weniger Probleme habe. Ich denke die CRC-Berechnung würde man schon in eine Tabelle bekommen. Es gibt ein Poly. und ein paar mal gedrehe mit Bitabhängigkeiten. Nichts anderes als bei einer "normalen" CRC denke ich. Grüße.
hi alle zusammen,
erstmal an alle fettes danke, super arbeit habt ihr hier alle
geleistet!!!
zu meinem prob: habe die Schaltung exakt nachgemacht, kriege aber keine
daten von meiner logamatic 2107.
interface habe ich gemäss update von chipsuffler nachgebaut. habe schon
viele interfaces im OBD (Automotive) Bereich gelötet, bin nicht ganz
anfänger und finde auch keinen fehler in meiner arbeit.
habe rx/tx auf beiden seiten schon wild hin und her getauscht. nix....
versuche die ganze zeit immer nach einem versuch fhem zu starten, debug
modus laufen zu lassen (verbose und loglevel auf 5 und 6) und logmode zu
setzen. nix...
(in der fhem.cfg ist natürlich auch "define KM271 KM271 /dev/ttyS0"
eingetragen)
wie testet ihr manuell? sprich senden von 0x02? mit nem PERL
write("\x02") sehe ich aller höchstens mal ne 00 aufm ttyS0 aber nix
gescheites.... und schon gar nicht irgendne antwort.....
interface wird natürlich mit abgas erkannt (bei nem 1k widerstand an FG
ca 150°C) und im service menü kann ich ne abgastemperaturschwelle
einstellen.
bin bischen verzweifelt, ist ja echt keine kunst das interface
eigentlich.
wisst ihr was sein könnte? typischer fehler auf den ihr auch gestossen
seid?
-die pegel an tx und rx nachmessen und dabei merken ob es wirklich richtig verbunden ist (war mein fehler) - mit einem seriell-usb Adapter und einem Terminal-programm erste Tuchfühlung nehmen. Ansonsten ist wohl eine genauere Beschreibung der gebauten Variante noitwendig, den thread kann wohl niemand mehr auseinander halten weil sich da verschiedene Stränge und Varianten durchmischen ... vg jens
was für pegel soll ich da erhalten? reicht ein voltmeter? mit was für einem terminalprogram kann ich sicher die einstellung 2400 vornehmen und hex 0x02 senden? bzw. wie machst du das?
Pegel messen (hier Logikpegel, keine RS232): - Verbindung auftrennen (also nichts anklemmen) - Am zu messenden Anschluß einen Widerstand ca. 4.7k gegen Masse legen. Ein Empfänger (Eingang) sollte dann gegen 0V zeigen, ein Ausgang knapp unter 5V Terminalprogramm: Realterm. Kann man alle Baudraten einstellen und auch senden. vg jens
Hallo, anbei die CRC-Berechnung für den EMS-Bus mit und ohne Tabelle. Grüße.
Gute morgen, sorry for my bad german... ich habe ein service key gekauft für EMS connection und habe eco soft Serial Communication gesehen mit advanced serial port monitor. Wass ich tun wolle: Eine wifi router mit linux oder PIC oder andern kleine Linux platform (Synology, Wdtv, ...) connectieren zum Service Key. Ich wollte warm wasser ein oder aus zu zetsen Ich wollte die HistorieDaten aus der Linux speichern. => Vorteil: Keine Ecosoft, keine Windows PC, aber lichte HW (kleine consumption). Glaubst du das die empfangen Hex Data einfach conertieren können? danke chris_be e.g. Start of comm: <20101106065709.928 TX> <STX> <20101106065711.922 TX> <STX> <20101106065712.004 RX> <DLE> <20101106065712.004 TX> <NUL><NUL><DLE><ETX><DC3> <20101106065712.041 RX> <DLE><STX> <20101106065712.089 TX> <DLE> <20101106065712.181 RX> <NUL><NUL><NUL><NUL>S<STX>1<DLE><ETX>s <20101106065712.181 TX> <DLE> <20101106065712.265 RX> <STX> <20101106065712.265 TX> <DLE> <20101106065712.360 RX> <NUL><NUL><SOH><NUL><NUL><NUL><ETX><NUL><SOH><ETX><DLE><ETX><DC3> <20101106065712.360 TX> <DLE> <20101106065712.390 RX> <STX> <20101106065712.390 TX> <DLE> <20101106065712.492 RX> <NUL><NUL><STX><NUL><BS><LF><FF><SO><DLE><DLE><DC2><DC4><SYN><CAN><SUB>< FS><RS><DLE><ETX><SOH> <20101106065712.492 TX> <DLE> <20101106065714.506 TX> <STX> <20101106065714.588 RX> <DLE> <20101106065714.588 TX> <EOT><BS><BEL><DLE><ETX><CAN> <20101106065714.640 RX> <DLE><STX> <20101106065714.691 TX> <DLE> <20101106065714.795 RX> <EOT><BS><BEL><NUL><VT><SOH><SOH><STX><NUL><NUL><NUL><NUL><NUL><NUL><NUL ><NUL><NUL><NUL><NUL><DLE><ETX><DC1> <20101106065714.795 TX> <DLE> <20101106065716.798 TX> <STX> <20101106065716.880 RX> <DLE> <20101106065716.880 TX> <EOT><BS><STX><DLE><ETX><GS> <20101106065716.940 RX> <DLE> <20101106065716.941 TX> <STX> <20101106065717.022 RX> <DLE> <20101106065717.022 TX> <EOT><HT><STX><DLE><ETX><FS> <20101106065717.089 RX> <DLE><STX> <20101106065717.089 TX> <DLE> <20101106065717.183 RX> <EOT><BS><STX><NUL>H<STX><EOT>K<STX><DC4><NUL><NUL><NUL><DLE><ETX><SO> <20101106065717.183 TX> <DLE> <20101106065717.240 RX> <STX> <20101106065717.240 TX> <DLE> <20101106065717.331 RX> <EOT><HT><STX><NUL>D<STX><NUL><DLE><ETX>Z <20101106065717.331 TX> <DLE> <20101106065719.329 TX> <STX> <20101106065719.411 RX> <DLE> <20101106065719.411 TX> <EOT><VT><STX><DLE><ETX><RS> <20101106065719.441 RX> <DLE> <20101106065719.441 TX> <STX> <20101106065719.523 RX> <DLE> <20101106065719.523 TX> <EOT><DLE><DLE><STX><DLE><ETX><NAK> <20101106065719.589 RX> <DLE><STX> <20101106065719.589 TX> <DLE> <20101106065719.682 RX> <EOT><DLE><DLE><STX><NUL>C<STX><BS><DLE><ETX>\ <20101106065719.682 TX> <DLE> etc...
Hallo Chris, Das ist ja super. Genau das nach dem ich gesucht habe. Die Kommunikation läuft wie schon fast vermutet über das 3964R-Protokoll. Leider hilft die Aufzeichnung von Dir leider garnichts da Du im ASCII-Mode aufgezeichnet hast. Zeichne doch mal im HEX-Mode auf. Wäre sehr interessant wie das genau abläuft. Einfach mal so eine Minute Log dann hier am besten als Datei anhängen. Und Bitte schau doch mal in der RC30/35 nach mit welcher Adresse und Namen er sich am Bus anmeldet. Bin echt neugierig. Bei der RC30: Service-Menü >> MonitorDaten >> Bus-Status. Bei der RC35: Diagnose >> Monitorwert >> Busteilnehmer Hier sind schon mal alle Daten die wir bisher herausgefunden haben: Beitrag "Re: Logamatic 2107 Schnittstelle" Die meisten Daten sind schon bekannt. Wir haben aber alle einen selbstgebastelten Controller und keinen Service-Key. Deswegen haben wir ein anderes Datenformat. Müsste bei Dir am Service-Key aber sehr ähnlich sein.... Gruß Ingo P.S.: Die Daten in Deinem Log, die nach HEX-Daten aussehen ist das Datum mit Uhrzeit und Millisekunden. Die eigentlich Daten sind dazwischen versteckt und werden evtl nicht komplett angezeigt weil es im ASCII-Mode von dem Programm aufgezeichnet wurde. Gruß Ingo
Habe mir mal die Mühe gemacht die Daten ohne den "Handshake" ins Hexformat zu übersetzen: 12.004 TX: 00 00 11 03 13 12.181 RX: 00 00 00 00 53 02 31 11 03s 12.360 RX: 00 00 01 00 00 00 03 00 01 03 11 03 13 12.492 RX: 00 00 02 00 08 0a 0c 0e 11 11 12 14 16 18 1a 1c 0e 11 03 01 14.588 TX: 04 08 07 11 03 18 14.795 RX: 04 08 07 00 0b 01 01 02 00 00 00 00 00 00 00 00 00 00 00 11 03 11 16.880 TX: 04 08 02 11 03 1d 17.022 TX: 04 09 02 11 03 1c 17.183 RX: 04 08 02 00 48 02 04 4b 02 14 00 00 00 11 03 0e 17.331 RX: 04 09 02 00 44 02 00 11 03 5a 19.411 TX: 04 0b 02 11 03 1e 19.523 TX: 04 11 11 02 11 03 15 19.682 RX: 04 11 11 02 00 43 02 08 11 03 5c Allerdings werden wohl viele Daten im ASCII-Modus nicht oder falsch angezeigt. z.B kommt das <DLE> in den Daten auch einzeln vor. Was nach dem 3964R-Protokoll nicht vorkommen darf. Stelle Dein Programm doch mal wie in dem Screenshot ein und dann im ASCII-Mode aufzeichnen.
Angehängte Dateien:
-
BUS.png
77 KB
guten abend. bitte: bus info Und eine Serial sniffer mit monitoring. Ich kannst Binary aufzeichern auch oder andern teste tun. ciao
Hallo Chris_be Danke für die Info... Der Service-Key versteckt sich also hinter der 0x0b ;o) Also zu den Daten.... Der Service-key sendet die Daten mit vorangestellter 0x04. dannach kommt die Adresse des EMS-Modul (0x10 für RC35) und dann der Telegrammtyp. Das hier aus Deinem Log ist das Telegramm 0x18 von der MC10: 04081900006101EE0225FFFFFF0000B9DA04786E02EA4803BAFF00AB590000100335 Mit der Tabelle kannst Du dann die Daten "decodieren". das 6.Byte ist die Außentemperatur 0x61 > 97 > 9,7°C Was die anderen Telegramme mit 0x39 und 0x00 sind kann ich jetzt auch nicht sagen. Würde mal vermuten dass die 0x00 Daten vom Service-Key selber sind. Ganz am Schluss sind noch Telegramme die mit 0x20 anfangen. Wird vermutlich nichts ganz so wichtiges sein. Die Telegramme mit der 0x39 am Ende kommen nicht vom Service-Key oder von der Software und sind nur ein Hinweis auf die Beschränkungen der TrialVersion. Vielleicht kannst Du ja noch mit hilfe der Buderus Software noch andere Daten herausfinden, was uns leider nicht möglich ist. Falls Du noch irgendwas herausfindest bitte dann noch mal posten oder mailen. Gruß Ingo
Ist ja fast ein Kinderspiel mit OpenOffice die unützen Daten herauszulöschen ;o) Für alle die es interessiert hier mal die reinen Daten ohne Ballast...
@Rudi Hier gibt es auch alle Versionsnummern die Du herausfinden wolltest :o) Ist alles Telegramm 0x02 und BIM die 0x04
1 | RX: 00 00 00 00 S Service Key 2.49 53 02 31 |
2 | RX: 04 21 02 00 E MM10 2.00 45 02 00 |
3 | RX: 04 08 02 00 H MC10 2.04 48 02 04 4B 02 14 00 00 00 |
4 | K SAFe 2.20 4B 02 14 |
5 | RX: 04 08 04 00 5001 17 13 89 11 82 12 3C 64 33 05 64 5A 32 |
6 | RX: 04 09 02 00 D BC10 2.00 44 02 00 |
7 | RX: 04 10 02 00 C RC30 2.08 43 02 08 |
8 | RX: 04 18 02 00 B RC20 1.04 42 01 04 00 00 00 |
Nun ist ja echt Bewegung in der Sache. Ich habe mir auch mal spaßhalber einen original Service Key zugelegt. Nun ist der Stecker etwas klobig und ich benötige eine Verlängerung zu meinem Hausautomationsserver. ;-) Was ist sinnvoller? Den Bus direkt zu verlängern (also am Klinkenstecker oder die RS232 Schnittstelle, die ich wohl noch über RS232 zu USB konvertieren muss? Gruß
Andreas F. schrieb: > Nun ist der Stecker etwas klobig und ich benötige eine Verlängerung zu > meinem Hausautomationsserver. ;-) Genau deswegen habe ich mich bisher geweigert den Service-Key zu kaufen ;o) Eigentlich ist es egal.Der EMS-Bus darf ja 50 Meter lang sein. Mit der seriellen Schnittstelle kommt kan bei 9600 laut Wikipedia bis zu 152Meter. Würde ich von dem Verkabelungsaufwand/-kosten abhängig machen. Das USB-Kabel zu verlängern halte ich nicht für eine gute Idee. Bei USB sind das ja mindestens 1,5MBit die über das Kabel gehen müssen. Bei 1 Meter würde vielleicht ein USB-Verlängerungskabel gehen. Halte ich aber trotzdem für keine gute Idee. Gruß Ingo
IngoF schrieb: > Eigentlich ist es egal.Der EMS-Bus darf ja 50 Meter lang sein. Na dann ist die Entscheidung leicht. Danke Dir. Gruß
Angehängte Dateien:
-
07011graphic.png
54 KB
Attachements: - Sending the config. - Get conf + Monitoring - Screenshot of Monitoring. enjoy!
Hello Chris.
Hier eine kleine Anleitung um die Daten automatisisert zu bereinigen:
[code]
###########################
1) unnütze Daten löschen:
###########################
bei "Mehr Optionen" "Regulärer Ausdruck" anklicken.
Ohne "" kopieren und in OpenOffice einfügen und jedes mal "Ersetzen
alle" anklicken.
suchen nach: ersetze durch:
(search for:) (replace by:)
----------------------------- --------------
"[[]len=[:digit:]+\x005d"
"1003[01234567890ABCDEF]{2}"
"<[RTX]{2}>$"
"<[RTX]{2}>[:digit:]{2}$"
"<[RTX]{2}>[:digit:]{4}$"
"^$"
"[01234567890ABCDEF]{2}" "& "
"10 10 " "10 "
###########################
2) alles Markieren:
###########################
"bearbeiten" "alles auswählen STRG+A" auswählen
###########################
3) in Zwischenablage:
###########################
"bearbeiten" "kopieren Strg+C" auswählen
###########################
4) in Wordpad einfügen:
###########################
WordPad öffnen
[STRG]+[V]
[\code]
und im Anhang die bereinigte Version.
Am besten die TXT-Datei gleich mit OpenOffice öffnen und die
Markroaufzeichnung starten. Alles bis Punkt 3 ausführen,
Makroaufzeichnung beenden und Makro abspeichern.
Dann geht alles beim nächsten mal viel schneller.
Aber dann nicht mehr das Ausgabeformat umstellen.
Gruß
Ingo
schon wieder Anhang vergessen.... @Chris poste doch mal Deine Programmeinstellungen vom "Advanced Serial Port Monitor" wie Du die Datei erstellt hast. Werde mich jetzt mal wieder um meine Hardware kümmern. Werde mir irgendwann mal ansehen was da in Deinem letzten Mittschnitt überhaupt drinsteht.... Gruß Ingo
@IngoF Wo ist deine Fernbedienung an der Heizung angeschlossen ? Bekommt die Fernbedienung nur GND und die Datenleitung oder zusätzlich noch die 12V ? Zum "get config": Die Daten sehen mir an einigen Stellen nach einem einfachen EEProm-Dump aus. Jedes Modul hat ja ein EEProm am I2C. Jetzt könnte man eine UART-Simulation schreiben und schauen was da so alles in der Software passiert ;-) @chris_be Is there a way to get pictures from inside the key ? Anyway, thanks for the log data !
Rudi schrieb: > Wo ist deine Fernbedienung an der Heizung angeschlossen ? Bekommt die > Fernbedienung nur GND und die Datenleitung oder zusätzlich noch die 12V > ? Also die RC30 und mein ATMega8 hängt im Wohnzimmer am Bus. Dann geht es an der Heizung vorbei ins Computerzimmer wo mein 18F2585 und hinter dem 4cm langen CAN BUS noch ein PIC. Der Bus hat keine 12 Volt also nur GND und 10/15Volt. Die 12 Volt gibt es nur an der Diagnosebuchse für den Service-key. Rudi schrieb: > Zum "get config": Die Daten sehen mir an einigen Stellen nach einem > einfachen EEProm-Dump aus. Jedes Modul hat ja ein EEProm am I2C. Also auf jeden Fall kommen einige Telegramme zerstückelt über den EMS-Bus. Der Service-Key klebt die zusammen und schickt die zum PC. Ansonsten sind die Telegramme alle gleich. Also am EMS-Bus sieht das Telegramm so aus: <Absender> <Empfänger> <Offset> <Daten ..... Daten> <"CRC"> <Break> Als Empfänger steht endweder 0x00 für alle, die "normale" Adresse (0x08=MC10) oder das Polling (0x88 für MC10) an dem Service-key zum PC (3964R): 0x04 <Absender> <Daten> <DLE(0x10)> <ETX(0x03)> <BCC(XOR)> Dabei werden alle 0x10 in den Daten gedoppelt damit sie von dem DLE unterschieden werden können. Vom Service-Key ein Telegramm mit den Schaltzeiten und anderen Daten: RX: 04 10 10 3F 00 01 21 00 84 21 21 ........ 10 03 <BCC> ^^^^^^ gedoppelt wegen 3964R sieht auf dem EMS-Bus dann so aus: 10 00 3F 00 ........ <CRC> 10 00 3F 1B ........ <CRC> 10 00 3F 36 ........ <CRC> ... ... ... Rudi schrieb: > Jetzt könnte man eine UART-Simulation schreiben und schauen was da so > alles in der Software passiert ;-) Also ich werde das auf jeden Fall mal in meine Hardware packen und evtl. mal testen ob es dann auch mit der Originalsoftware läuft... Vermute mal dass es dort keine Probleme gibt. Wie man sieht fragt die OriginalSoftware erst mal die Versionsnummern mit dem Telegrammtyp 02 ab. Dannach werden alle Telegramme vom Busteilnehmer abgefragt. Also scheint der Servicekey verschiedene Abfragemethoden zu haben. Spezielle Telegramme, oder alle Telegramme. 04 10 02 fragt also die Seriennummern ab (Telegramm 0x02) 04 10 fragt dann alle Telegramme ab (auch noch mal 0x02) Wie man ja sieht gibt es also dann noch einige Telegrammtypen die bei mir noch nie auf dem Bus aufgetaucht sind.. Beim Konfig senden sieht man sogar noch mehr Telegramme die Teilweise nur aus Nullen bestehen... Gruß Ingo
Achso... Ob das Offset bei dem EMS-Beispiel jetzt stimmt kann ich nicht garantieren. Müsste noch mal auf dem BUS mitlesen. Meine aber mich an die 0x1B als erstes zu erinnern. Es gibt aber auch eine Möglichkeit nur einzelne Werte zu setzen. Die kommen eigentlich nur von der RC30 bei mir und gehen zur MC10 oder seltener zu der 0x09...
IngoF schrieb: >> Jetzt könnte man eine UART-Simulation schreiben und schauen was da so >> alles in der Software passiert ;-) > > Also ich werde das auf jeden Fall mal in meine Hardware packen und evtl. > mal testen ob es dann auch mit der Originalsoftware läuft... Vermute mal > dass es dort keine Probleme gibt. Ja, ich hatte es damals über VirtualBox und über eine externe Loop versucht, aber da kannte ich das Format noch nicht. Jetzt sollte es, auch ohne Hardware, einfacher sein ... ;-)
Verstehe nur Bahnhof :o) Wie oder was wolltest Du denn machen? Hast Du die Originalsoftware und möchtest dann den Service-Key simulieren? Dann an irgendwelchen Parametern herumdrehen und sehen was sich in der Original-Software ändert? In die andere Richtung experimentiern und irgendwelche Wert umzustellen um zu sehen was sich an der Heizung ändert ist bestimmt nicht so eine gute Idee.. Aber das könnte man auch direkt am EMS-Bus machen. Ich habe vor das direkt in meine Hardware zu programmieren dass sie sich auch wie ein Service-Key verhält. Oder eben irgend ein beliebiges anderes Protokoll. Nur muss ich dann doch wohl irgenwie externen Speicher für meinen Controller spendieren. Mit dem internen 1,5K RAM wirds dann eng. Und dann kann ich mir immer noch die Original-Software mal ansehen ;o)
IngoF schrieb: > Wie oder was wolltest Du denn machen? > Hast Du die Originalsoftware und möchtest dann den Service-Key > simulieren? Dann an irgendwelchen Parametern herumdrehen und sehen was > sich in der Original-Software ändert? Ich hatte damals zwei serielle Schnittstellen verbunden und an einer Seriellen die Software und an der anderen ein Terminal bzw. ein kleines Skript um zu sehen was dort passiert. > In die andere Richtung experimentiern und irgendwelche Wert umzustellen > um zu sehen was sich an der Heizung ändert ist bestimmt nicht so eine > gute Idee.. Aber das könnte man auch direkt am EMS-Bus machen. Ja, dann aber nur im Sommer ;-) > Ich habe vor das direkt in meine Hardware zu programmieren dass sie sich > auch wie ein Service-Key verhält. Oder eben irgend ein beliebiges > anderes Protokoll. Nur muss ich dann doch wohl irgenwie externen > Speicher für meinen Controller spendieren. Mit dem internen 1,5K RAM > wirds dann eng. Es gibt 32K externes SPI-SRAM von Microchip. Ich werde einen STM32 zum parsen benutzen. 20K SRAM sollten reichen, ansonsten hat er noch etwas externes SRAM.
IngoF schrieb: Nur muss ich dann doch wohl irgenwie externen > Speicher für meinen Controller spendieren. Mit dem internen 1,5K RAM > wirds dann eng. > > Und dann kann ich mir immer noch die Original-Software mal ansehen ;o) Ich habe eine PIC zum hause mit eine Ethernet connection. Es registriert data (Onewire, Serial, ...) und sended UDP packet zum Synology NAS. On synology brauche ich Netcat UDP port >file.txt so brauche ich keine speicher am PIC Wenn ich zeit habe wollte ich neue Serial data logs senden, diese abend.
Angehängte Dateien:
-
RC30_betriebswerte.png
53 KB -
Warmwasser.png
39 KB -
Monitordaten2.png
48 KB -
Monitordaten1.png
46 KB -
monitoring0911.png
150 KB
as promised
Acho, erst werden einmal alle Werte abgefragt z.B. 04 08 18 ..... und hinterher kommen die einzelwerte 20 04 08 18 ... <TX>20 04 <RX>20 04 08 18 02 D0 <RX>20 04 08 18 02 D5 <RX>20 04 08 18 05 09 <RX>20 04 08 18 1E 82 <RX>20 04 08 18 1F 74 <RX>20 04 10 06 04 0C <RX>20 04 10 06 05 3A <RX>20 04 08 34 02 E1 <RX>20 04 08 18 1E 80 <RX>20 04 08 18 1F 75 <RX>20 04 08 18 02 DA <RX>20 04 08 18 1E 82 <TX>20 04 interessant ist auch dass nur einzelne geänderte Werte übertragen werden. z. Beispiel an der Kesseltemperatur mit dem Offset 01 und 02. Auch dort wird nur ein Byte übertragen. also so bald sich ein Byte ändert wird nur das Byte übertragen und nicht beider Werte der Temperatur. Also hat die Software und der Servicekey irgendwo einen Buffer wo alle alten Werte zwischengespeichert werden. @Chris_be Die Software pollt also in einem bestimmten Abstand den Service-Key an (<TX>20 04 ). Kannst Du in dem original-Log noch erkennen in welchem Zeitabstand das passiert? Oder sieht das nur so aus als obe das regelmäßig passiert? Gruß Ingo
Hi Ingo, beispiel von original Log: Zeit is ... 2 sek? Start: <20101109201120.688 RX> 02 <20101109201120.688 TX> 10 <20101109201120.778 RX> 2004081802D51003F0 <20101109201120.778 TX> 10 <20101109201120.812 RX> 02 <20101109201120.812 TX> 10 <20101109201120.902 RX> 20040818050910032B <20101109201120.902 TX> 10 <20101109201120.942 RX> 02 <20101109201120.942 TX> 10 <20101109201121.033 RX> 200408181E821003BB <20101109201121.033 TX> 10 <20101109201121.062 RX> 02 <20101109201121.062 TX> 10 <20101109201121.153 RX> 200408181F7410034C <20101109201121.157 TX> 10 <20101109201121.212 RX> 02 <20101109201121.212 TX> 10 <20101109201121.304 RX> 2004101006040C100339 <20101109201121.304 TX> 10 <20101109201121.387 RX> 02 <20101109201121.387 TX> 10 <20101109201121.478 RX> 2004101006053A10030E <20101109201121.488 TX> 10 <20101109201121.529 RX> 02 <20101109201121.529 TX> 10 <20101109201121.619 RX> 2004083402E11003E8 <20101109201121.619 TX> 10 <20101109201122.988 RX> 02 <20101109201123.021 TX> 10 <20101109201123.111 RX> 200408181E801003B9 .... Ende: <20101109202134.018 TX> 02 <20101109202134.215 RX> 10 <20101109202134.215 TX> 2004100337 <20101109202134.249 RX> 10 <20101109202136.299 TX> 02 <20101109202136.347 RX> 021002 <20101109202138.286 TX> 10 <20101109202138.375 RX> 2004081903F01003D5 <20101109202138.397 TX> 10 <20101109202138.435 RX> 02 <20101109202138.436 TX> 10 <20101109202138.532 RX> 2004081905F01003D3 <20101109202138.532 TX>
Hallo Ingo, Ingo F. schrieb: > Also sie wird sehr wahrscheinlich einfach nur ein 82 oder 100 Ohm > Emitterwiderstand für die Stromregelung haben und mit dem Basis am > PIC/Atmega8 hängen. Dann sollte der Strom passen. Hast du schon einen konkreten Wert ? Welche Kapazitäten benutzt du um den Bus zu glätten (Stromversorgung hinter den Dioden). Grüße.
Rudi schrieb: > Hast du schon einen konkreten Wert ? Nö, leider nicht. Muss noch fleissig programmieren und finde nicht wirklich oft Zeit dafür. Allerdings müssten beide funktionieren Im Moment hört mein Controller garnicht mehr auf zu senden und hängt in einer Endlosschleife die mir unerklärlich ist :o) Kann ja schlecht an der "Sendestufe" basteln wenn nichts zu senden ist. @Chris ich meinte den Abstand zwischen dem senden dieses Telegramme, das vermutlich immer in bestimmten abständen kommt: > <20101109202134.215 TX> > 2004100337 Gruß Ingo
Hi, ich bin grad mal wieder mit dem Oszi an der Heizung um die Sendefunktion zu implementieren. So wie ich das sehe kommt die abzufragende Adresse mit bit 7 gesetzt und danach das Break. Wenn der Buspegel auf 1 ist, sendet die angefragte Station mit genau 1 Byte und wartet auf das "Busecho", wenn alles stimmt das nächste usw.. Am Ende der Übertragung schickt die Station ein Break. Ich benutze einen FET und 50 Ohm Serienwiderstand. Wenn die Anfrage nicht beantwortet werden kann, fliegt die Station aus der Liste und bei der nächsten erfolgreichen Anfrage ist sie wieder dabei. Grüße.
cool... wie hast Du dass denn hinbekommen? Welches Telegramm war das denn?
IngoF schrieb: > cool... > > wie hast Du dass denn hinbekommen? Welches Telegramm war das denn? Ich warte auf das 0x8B BRK und antworte danach so schnell wie möglich mit 0x0B BRK. Nach jedem gesendeten Zeichen musst du den Bus auslesen, um das Echo (dein gesendetes Zeichen) zu verifizieren. Wenn der Bus auf Low liegt, kann man wohl nicht senden. Das Zurücklesen habe ich bisher nur durch ein Delay realisiert (etwas länger als ein Frame) und ich schau auch nicht ob ich zu spät sende (Kollision mit einer anderen Station), weswegen die Station ab und zu aus der Liste rausfliegt. Grüße.
Rudi schrieb: > Ich warte auf das 0x8B BRK und antworte danach so schnell wie möglich > mit 0x0B BRK. Nach jedem gesendeten Zeichen musst du den Bus auslesen, > um das Echo (dein gesendetes Zeichen) zu verifizieren. Wenn der Bus auf > Low liegt, kann man wohl nicht senden. Ja, das war mir schon klar.... Wie hast Du denn das "COMPUTER" auf die RC-30 gezaubert? Bei mir steht bei unbekannten Adressen nur "GERÄT". Liegt dann wohl vermutlich an Deiner neueren Firmware der RC30 und nicht an einem Telegramm in der man den Namen des Busteilnehmers übergeben kann... Gruß Ingo
Hallo, IngoF schrieb: > Wie hast Du denn das "COMPUTER" auf die RC-30 gezaubert? Bei mir steht > bei unbekannten Adressen nur "GERÄT". Liegt dann wohl vermutlich an > Deiner neueren Firmware der RC30 und nicht an einem Telegramm in der man > den Namen des Busteilnehmers übergeben kann... Kennt deine Firmware den Servicekey noch nicht ? Grüße.
Nöö, bei allen "unbekannten" Adressen steht bei mir Gerät. Meine auch bei der 0x0b für den Service-Key.
Hallo, ich klinke mich hier auch mal ein, da wir in den nächsten Wochen eine neue GB172 Heizung mit RC35 Steuerung bekommen. Ich denke, dass ist doch EMS-Bus, oder? Ich möchte gern einige Daten der Heizung dauerhaft mitloggen und da bin ich auf diesen Beitrag gestoßen. Was empfehlt Ihr mir, wo ich die Daten abgreife? An der Service-Schnittstelle oder am 2-adrigen Kabel zur RC35? Was brauche ich da an Pegelwandler? Wie ich das verstanden habe verwendet der EMS-Bus 9600 Baud? Sorry, ich bin Windows-Softwareentwickler, werde mir eine passende Windows-Software schreiben, aber von der Elektronik habe ich nicht so eine tiefgreifende Ahnung. Vielleicht kann mir auch jemand so einen Pegelwandler anbieten mit einer seriellen Schnittstelle, wo ich dann "nur noch" meine Software horchen lassen kann. Danke schonmal. Dirk
Noch eine andere Frage: Was steckt in dem Original Service-Key? Ich würde den sonst nachbauen oder vielleicht hat den jemand gebraucht abzugeben. Die Software hat mein Heizi als Demo-Version, das würde mir erstmal reichen, bräuchte nur den Service-Key...
Hallo, Dirk Janssen schrieb: > Was empfehlt Ihr mir, wo ich die Daten abgreife? An der > Service-Schnittstelle oder am 2-adrigen Kabel zur RC35? Ich habe zuerst mit der 3-Draht Lösung gearbeitet und benutze jetzt die 2-Draht Lösung, die funktioniert soweit. Mich stört aber noch die fehlende galvanische Trennung, weil ich die Heizung nicht mit der Hausinstallation verbinden will. Dirk Janssen schrieb: > Was brauche ich da an Pegelwandler? Wie ich das verstanden habe > verwendet der EMS-Bus 9600 Baud? Du brauchst einen Komparator. Ingo hat die Schaltung weiter oben schon gepostet. Dirk Janssen schrieb: > Noch eine andere Frage: Was steckt in dem Original Service-Key? Ich > würde den sonst nachbauen oder Siehe oben. > vielleicht hat den jemand gebraucht > abzugeben. Die Software hat mein Heizi als Demo-Version, das würde mir > erstmal reichen, bräuchte nur den Service-Key... Tja, wenn es den so "billig" geben würde, würde es diesen Thread nicht geben.
Rudi schrieb: > Ich habe zuerst mit der 3-Draht Lösung gearbeitet und benutze jetzt die > 2-Draht Lösung, die funktioniert soweit. Warum hast du dich denn umentschieden? Gibt es da Vorteile? Habe meine "Servicekeylösung" nun am laufen und parse einige Daten mit einem Arduino-Clone (Jeenode) und funke die zu meinem Server. Kann man den Servicekey eigentlich "emulieren"? Wie schmeisst der denn die Daten an den Rechner raus? Steige langsam nicht mehr durch bei der Mischung hier ;-)
Fred Granna schrieb: > Rudi schrieb: >> Ich habe zuerst mit der 3-Draht Lösung gearbeitet und benutze jetzt die >> 2-Draht Lösung, die funktioniert soweit. > > Warum hast du dich denn umentschieden? Gibt es da Vorteile? Ein Vorteil (und Grund für mich, die 2-Draht-Variante zu nehmen) ist auf alle Fälle, dass man den Bus irgendwo zwischen Brenner und RC30/35 abgreifen kann. Dadurch hat man keine komisch rumhängenden Kabel - im Keller mag das ja ok sein, bei mir steht die Heizung aber im HWR, da soll es schon ordentlich aussehen ;-)
Hallo, Fred Granna schrieb: > Warum hast du dich denn umentschieden? Gibt es da Vorteile? Hauptsächlich wegen der offenen Klappe. Im Keller staubt die schön. Außerdem musste ich immer den Stecker ziehen, damit die Heizungsleute hinter die Abdeckung kommen. Ich suche jetzt eigentlich noch eine Isolationsmöglichkeit für die RX/TX-Leitung. Durch die 2-Draht Lösung gibt es nicht mehr viel Strom. Fred Granna schrieb: > Kann man den Servicekey eigentlich "emulieren"? Wie schmeisst der denn > die Daten an den Rechner raus? Steige langsam nicht mehr durch bei der > Mischung hier ;-) Schau dir die Posts von chris_be und IngoF an, dort steht einiges darüber.
Rudi schrieb: > Hallo, > > Fred Granna schrieb: >> Warum hast du dich denn umentschieden? Gibt es da Vorteile? > > Hauptsächlich wegen der offenen Klappe. Im Keller staubt die schön. Ahso. Ich hab gleich einen abgewinkelten Stecker genommen. Klappe ist bei mir also zu :)
Hi Fred, kannst Du bitte mal was zu deiner Jeenode-Lösung posten ? Fred Granna schrieb: > Habe meine "Servicekeylösung" nun am laufen und parse einige Daten mit > einem Arduino-Clone (Jeenode) und funke die zu meinem Server. Gruss Guenne
Würde ja auch gerne was neues erzählen :o( ... dummerweise funktioniert mein Programm auf dem PIC im MPLAB-Debugger einwandfrei aber nicht im Betrieb. Und meinen Debugmode im PIC selber mit PicKit3 kann ich im MPlab nicht aktivieren. Falls irgendjemand irgendwann eine Idee haben könnte wie man in den Debugmode beim PIC18F258 kommt wäre ich für jeden Hinweis dankbar. Vielleicht verirrt sich ja mal ein PIC-Nutzer in diesen Thread ;o) Rudi schrieb: > Ich suche jetzt eigentlich noch eine Isolationsmöglichkeit für die > RX/TX-Leitung. Durch die 2-Draht Lösung gibt es nicht mehr viel Strom. @Rudi, meintest Du damit eine galvanische Trennung? Wäre das einfachste nicht jeweils ein Optokoppler für die RX und TX-Leitung direkt am Controller? Der Strom für die Sende/Empfangsschaltung sollte ja kein Problem sein... Gruß Ingo
Hallo, ich habe keinen PIC aber schau mal dort, evtl. ist es das schon: Beitrag "Debugging mit PICKIT3?" IngoF schrieb: > meintest Du damit eine galvanische Trennung? Wäre das einfachste nicht > jeweils ein Optokoppler für die RX und TX-Leitung direkt am Controller? > Der Strom für die Sende/Empfangsschaltung sollte ja kein Problem sein... Ja, eine galvanische Trennung. Mit LDO und Optokoppler funktioniert es bei mir nicht mehr, der Bus spinnt dann rum (mit der 2-Draht Variante). Mit der 3-Draht Variante habe ich es nur mit einem Funktionsgenerator und externer VCC probiert. Offensichtlich reicht der Strom nicht aus.
Hallo, mal etwas Semi-OT. Wurde bei euch in der Logomax schonmal der Lüfter für den Brenner getauscht ? Nach einer längeren Wartungsarbeit gabs nur 6L / 229 und keine Flamme. Der Lüfter ist auch etwas laut, meinte der freundliche Heizungsfachmann. Nach mehreren Versuchen der Heizungsanlage, von Flamme an auf Fehlermeldung, lief es dann irgendwann wieder wie geschmiert. Grüße.
Angehängte Dateien:
-
EMS_Interface.png
180 KB
hi rudi, was hast du denn genau für ein gerät? logamax ist nur so eine art familienname für wandhängende heizgeräte. @ all bei der gelegenheit möchte ich mich auch gleich in sachen ems an bord melden. im gegensatz zu den meisten hier, habe ich nicht das ziel daten zu loggen, sondern meinen Brennwertkessel (gb142) durch die vorgabe eine brennerleistung anzusteuern. am ende soll eine außentemperaturgeführte rücklaufregelung dabei herauskommen. ich habe vor das telegramm des moduls em10 zu ermitteln um es dann mit einem avr zu emulieren. das em10 hat die fähigkeit ein ems-heizgerät temperatur- oder leistungsgeführt anzusteuern, wobei es selbst ein 0-10v signal als führungsgröße hat. an dieser stelle auf jeden fall schon mal einen herzlichen dank an die beiden ems-hauptakteure rudi und ingo. soweit wäre ich aus mangel an equipment und know-how nie gekommen. ich arbeite übrigens seit 18 jahren als servicetechniker des werkskundendienstes von buderus. achso ... ich habe mal das bus interface eines moduls mm10 aufgedröselt und zu 'papier' gebracht (siehe anhang). //niffko
Niff Ko schrieb: > was hast du denn genau für ein gerät? logamax ist nur so eine art > familienname für wandhängende heizgeräte. Das ist die GB152. Niff Ko schrieb: > achso ... ich habe mal das bus interface eines moduls mm10 aufgedröselt > und zu 'papier' gebracht (siehe anhang). Das ist doch mal etwas. Hast du zufällig Angaben für den maximalen Strom für die einzelnen Komponenten am Bus ? Werden die 5V aus der VREF erzeugt ? Niff Ko schrieb: > am ende soll eine außentemperaturgeführte > rücklaufregelung dabei herauskommen. Du willst über die Temperaturdifferenz Vorlauf/Rücklauf (Wärmeabgabe) den Brenner steuern ? Ohne das Wissen der momentanten Zirkulation wird das nicht funktionieren, es sei denn du zapfst noch einen Wärmemengenzähler an. Wenn ich dich richtig verstanden habe ;-) Danke & Grüße.
hi rudi, > Das ist die GB152. das gebläse gehört bei 6L/229 erst mal nicht zu den üblichen verdächtigen. abnormale geräusche kommen in der regel vom lager, hatte ich hin und wieder schon. fehler 6L bedeutet, dass das flammensignal (ionisation) vorhanden war aber dann zusammengebrochen ist. hier hätte man sich bei auftreten des fehlers mal den wert des flammenstromes im monitor anschauen können. evtl. schwächelt deine ionisationselektrode, die zeigen manchmal erst bei längerer auskühlung ihr wahres gesicht. >Hast du zufällig Angaben für den maximalen Strom >für die einzelnen Komponenten am Bus ? negativ. >Werden die 5V aus der VREF erzeugt ? nein. U_REF -> ~0,6V, die geht lediglich auf die komparatoren. 5V kommen vom netzteil des moduls. > Du willst über die Temperaturdifferenz Vorlauf/Rücklauf (Wärmeabgabe) > den Brenner steuern ? Ohne das Wissen der momentanten Zirkulation wird > das nicht funktionieren, es sei denn du zapfst noch einen > Wärmemengenzähler an. Wenn ich dich richtig verstanden habe ;-) du meinst, die abgegebene wärmemenge berechnen und dann eine entsprechende brennerleistung vorgeben? nein. anstatt wie üblich abhängig von der aussentemperatur die vorlauftemperatur auszuregeln, wird bei der rücklaufregelung - du ahnst es bereits - die rücklauftemperatur als führungsgröße benutzt. das hat ein paar vorteile, googel das mal. //niffko
Angehängte Dateien:
-
vlrl.png
84 KB
Niffko schrieb: > du meinst, die abgegebene wärmemenge berechnen und dann eine > entsprechende brennerleistung vorgeben? nein. anstatt wie üblich > abhängig von der aussentemperatur die vorlauftemperatur auszuregeln, > wird bei der rücklaufregelung - du ahnst es bereits - die > rücklauftemperatur als führungsgröße benutzt. das hat ein paar vorteile, Die Vorteile sind mir schon klar, aber schau dir mal das Bild im Anhang an. Die Rücklauftemperatur sinkt, da die Thermostate zu gemacht haben, es gibt so gut wie keine Zirkulation mehr. Der Vorlauf fährt brav seine Kurven, durch Mikrozirkulation etc.. Wenn du nun die Rücklauftemperatur als Führungsgröße nimmst, würde der Vorlauf ansteigen ohne nennenswerte Änderung der Führungsgröße (Rücklauftemperatur). Wie willst du das Problem ohne weitere Regelgrößen erschlagen ? Grüße.
Gibts eigentlich noch mehr Informationen über die Telegramme des Servicekeys? Habe schon einiges raus (anhand der Listen und PDFs hier). Mir fehlt allerdings z.B. noch die RÜcklauftemperatur.
IngoF schrieb: > Na dann hast Du nicht richtig gesucht: > Beitrag "Re: Logamatic 2107 Schnittstelle" > > Gruß > Ingo Hallo und Danke. Das hatte ich auch schon gefunden. Allerdings bekommen ich die Daten für Druck und Rücklauf nicht (nur werte von 128 oder 255 die sich nicht ändern). Die anderen Werte bekomme ich ordentlich raus. Bissl komisch
Fred schrieb: > Hallo und Danke. Das hatte ich auch schon gefunden. Allerdings bekommen > ich die Daten für Druck und Rücklauf nicht (nur werte von 128 oder 255 > die sich nicht ändern). Die anderen Werte bekomme ich ordentlich raus. Werden die digitalen Werte an der Anlage richtig angezeigt ?
Ja, alles ok. Brennerstatus, Flamme,Zündung, Pumpe HKx, Ventile, Flammenstrom, Kessel-Soll,Kessel-Ist, WW etc.pp. das geht soweit alles. Rudi schrieb: > Fred schrieb: >> Hallo und Danke. Das hatte ich auch schon gefunden. Allerdings bekommen >> ich die Daten für Druck und Rücklauf nicht (nur werte von 128 oder 255 >> die sich nicht ändern). Die anderen Werte bekomme ich ordentlich raus. > > Werden die digitalen Werte an der Anlage richtig angezeigt ?
Fred schrieb: > Allerdings bekommen > ich die Daten für Druck und Rücklauf nicht (nur werte von 128 oder 255 > die sich nicht ändern). Die anderen Werte bekomme ich ordentlich raus. > Bissl komisch Hallo Fred, kann dann ja eigentlich nur mit dem Softwarestand Deiner Busteilnehmer zusammenhängen oder mit Deiner Anlage. Wie sieht dass denn bei Dir aus? Gruß Ingo
Fred schrieb: > Ja, alles ok. Brennerstatus, Flamme,Zündung, Pumpe HKx, Ventile, > Flammenstrom, Kessel-Soll,Kessel-Ist, WW etc.pp. das geht soweit alles. Ich meinte die beiden Werte die du per ServiceKey nicht richtig siehst.
@Ingo F. Wie sieht was bei mir aus? :-) Ist eine Logamax Plus GB172 mit BC10 und RC35. @rudi Was meinst du genau? Die Softwareversionen kann ich erst heute Abend abfragen.
Fred schrieb: > @rudi > Was meinst du genau? Zeigt die Anlage den Druck und den Rücklauf richtig an ? Also die beiden Werte bei denen du nur 128 und 255 auf der seriellen Schnittstelle siehst.
Rudi schrieb: > Fred schrieb: >> @rudi >> Was meinst du genau? > > Zeigt die Anlage den Druck und den Rücklauf richtig an ? Also die beiden > Werte bei denen du nur 128 und 255 auf der seriellen Schnittstelle > siehst. Ah, das meinst du. Zu finden ist das im Servicemenü der BC10? Muss ich nachher gleich mal schauen.
Fred schrieb: > Allerdings bekommen > ich die Daten für Druck und Rücklauf nicht (nur werte von 128 oder 255 > die sich nicht ändern). ... das ist schon o.k. so - der gb172 hat weder rücklauf- noch drucksensor. Fred schrieb: > Ist eine Logamax Plus GB172 mit BC10 und RC35. der bc10 heißt beim 172er bc25 ;-) //niffko
Rudi schrieb: > Die Vorteile sind mir schon klar, aber schau dir mal das Bild im Anhang > an. Die Rücklauftemperatur sinkt, da die Thermostate zu gemacht haben, > es gibt so gut wie keine Zirkulation mehr. Der Vorlauf fährt brav seine > Kurven, durch Mikrozirkulation etc.. hmm ... was meinst du mit mikrozirkulation? evtl. die zirkulation im gerät über einen bypass (überströmventil), wenn der heizkreis dicht gemacht hat? deine rücklauftemperatur dürfte sich normalerweise nicht wie von dir beschrieben verhalten. der rücklauffühler sitzt innerhalb des bypasskreises, die rücklauftemperatur müsste also bei geschlossenen thermostatventilen mit nur geringem delta der vorlauftemperatur folgen. Rudi schrieb: > Wie willst du das Problem ohne weitere Regelgrößen erschlagen ? das problem stellt sich bei mir nicht. ich habe die heizkreise meiner fußbodenheizung abgeglichen und die heizkennlinie entsprechend angepasst. so benötige ich keine zonenventile, die heizkreise sind also immer offen. //niffko
Niffko _ schrieb: > hmm ... was meinst du mit mikrozirkulation? evtl. die zirkulation im > gerät über einen bypass (überströmventil), wenn der heizkreis dicht > gemacht hat? Das warme Wasser steigt nach oben und Zirkuliert oder ein Ventil ist nicht 100%ig zu etc.. Das meinte ich damit. Meine Temperatursensoren an den Rohren sehen ab und zu etwas zuviel bzw. sind nicht träge genug. > deine rücklauftemperatur dürfte sich normalerweise nicht > wie von dir beschrieben verhalten. der rücklauffühler sitzt innerhalb > des bypasskreises, die rücklauftemperatur müsste also bei geschlossenen > thermostatventilen mit nur geringem delta der vorlauftemperatur folgen. Das ist eine Rücklauftemperatur von 3 Heizkreisen, ob es einen Bypass gibt, kann ich nicht sagen. Wie es sich mit dem Hauptrücklauf verhält, wenn alle 3 Heizkreise dicht gemacht haben, weiss ich noch nicht. Ich werde das demnächst mal ausprobieren. Grüße.
Rudi schrieb: > Das ist eine Rücklauftemperatur von 3 Heizkreisen ... ich war davon ausgegangen, dass es sich um einen ems-wert handelt. dann hätte es nur der kesselrücklauf sein können, da keine heizkreisrückläufe erfasst werden. ob an deinen heizkreisen überströmventile vorhanden sind, weiß ich natürlich nicht. deine gb152 jedenfalls ist mit einem internen überströmventil ausgestattet. ich habe nur einen ungemischten heizkreis, daher ist kesseltemperatur gleich heizkreistemperatur und ich kann den ems-wert des kesselrücklaufes als führungsgröße benutzen. //niffko
Hallo, ich hab seit ein paar Monaten eine GB 162 und würde gern zur Optimierung der Anlage die Daten zumindest wochenweise mit einem alten Notebook aufzeichnen und mit der Buderus Software auswerten. Laut Buderus kostet der dazu erforderliche Service Key 214.-€. Wenn ich mir den Thread so durchlese scheinen es einige unter euch geschafft zu haben einen "ServiceKey" selbst zu basteln. Funktionieren diese Lösung tatsächlich so, dass die gleichen Monitorwerte wie mit dem original ServiceKey ausgelesen werden können ? Mit welchen Kosten ist so ein Eigenbau zu realisieren, sprich rechnet sich der Aufwand im Vergleich zu Originalteil ? Viele Grüße buddi
Hallo, buddi schrieb: > Funktionieren diese Lösung tatsächlich so, dass die gleichen > Monitorwerte wie mit dem original ServiceKey ausgelesen werden können ? Nein, dort siehst du direkt den EMS-Bus. > Mit welchen Kosten ist so ein Eigenbau zu realisieren, sprich rechnet > sich der Aufwand im Vergleich zu Originalteil ? Ich denke nicht mehr als 10€ für die Bauteile.
Hallo, > Funktionieren diese Lösung tatsächlich so, dass die gleichen > Monitorwerte wie mit dem original ServiceKey ausgelesen werden können ? Nein, dort siehst du direkt den EMS-Bus. ...ähm - wie muss ich mir das vorstellen, welche Daten bekomm ich da geliefert und werden die mit der Buderus-Software angezeigt ? > Mit welchen Kosten ist so ein Eigenbau zu realisieren, sprich rechnet > sich der Aufwand im Vergleich zu Originalteil ? Ich denke nicht mehr als 10€ für die Bauteile. ...bekomm ich das als normaler Bastler mit einer kleinen Anleitung hin ? Gruß buddi
Hallo, buddi schrieb: > ...ähm - wie muss ich mir das vorstellen, welche Daten bekomm ich da Die Daten/Telegramme vom EMS-Bus (siehe weiter oben). Mit Service Key sieht es etwa so aus: EMS-Bus (EMS-Telegramme) -> ServiceKey (Service Key Protokoll) -> Buderus Software oder Terminal Mit dem Nachbau so: EMS-Bus (EMS-Telegramme) -> Nachbau (EMS-Telegramme) -> Terminal > geliefert und werden die mit der Buderus-Software angezeigt ? Nein, die versteht das Format nicht direkt, nur wenn die Daten aufbereitet werden, wie durch den ServiceKey. > ...bekomm ich das als normaler Bastler mit einer kleinen Anleitung hin ? Ich denke das sind alles Teile die du bei R. bestellen kannst. Es gibt hier im Thread mindestens 3 Schaltungen. Das EMS-Protokoll ist hier auch etliche male beschrieben worden, zumindestens alle wichtigen Teile zur Überwachung der aktuellen Werte und Einstellungen. Grüße.
Nabend, ich habe jetzt das Senden an die Anlage hinbekommen :=) ServiceKey ist in der Geräteliste aufgeführt, also alles bingo :-D Jetzt versuche ich die ganze Sache mit der ECO-SOFT zu verbinden. Dazu schnüffel ich grad ein wenig am COM-Port des Rechners rum. Nun meine Fragen: 1. Ist es richtig das die Software als erstes ein 0x02 sendet? 2. Wenn ich auf dieses 0x02 mit 0x10 antworte bekomme ich 0x00 0x00 0x10 0x03 0x13; Was bedeuten diese Werte überhaupt? 3. Auf den obigen String antworte ich mit 0x10 0x02. Daraufhin bekomme ich 0x10 von der Software zurück. Da ich dann nichts mehr antworte, gibt mir die Software die Fehlermeldung "Keine ComKarte gefunden !!!" Woher weiss ich eigentlich das ein "Telegramm" von der Software komplett gesendet wurde? Kommt z.B. nach "0x00 0x00 0x10 0x03 0x13" ein UART-Break? Trennzeichen habe ich da nirgends :-/
Das sollte die Prozedur 3964R sein. Habe mal meine Erkenntnisse aus den Logs von Chris_be hier gepostet: Beitrag "Re: Logamatic 2107 Schnittstelle" Beitrag "Re: Logamatic 2107 Schnittstelle" generell kommt ein 04 davor. Bei einzelnen geänderten Werten zusätzlich noch eine 20. Die Originalsoftware fragt erst alle Seriennummern der Busteilnehmer und anschließend alle Telegramme ab. Dannach könnte man mit den Monitorwerten, die ja änderungen der einzelnen Bytes im Telegramm sind, alle Änderungen verfolgen, Gruß Ingo
Hm, das hatte ich schon gesehen. Derzeit sende ich allerdings nichts an den Bus sondern habe als Gegenstelle zur ECO-SOFT einen Atmega zur Analyse. Das erste was ich von der ECO-SOFT bekomme ist einfach nur 0x02. Mehr nicht, auch leider keine Trennzeichen. Wenn ich darauf nicht antworte kommen noch 2x "0x02" nacheinander und dann 0x15 (ist wohl der Abbruch). Das mit den nicht vorhandenen Telegrammstrennern stört mich ein wenig. Wenn ich das dann später auf den Bus schicke muss ich doch wissen wann ich ein BREAK setzen muss oder?!
Das ist das Handshake vom 3964R-Protokoll. Es gibt dort kein Break. Das wird alles über das 3964R-Protokoll gemacht. Einfach mal googeln. Die eigentlichen Daten kommen dann erst. Erst mal fragt die Ecosoft alle Busteilnehmer nach den Serienummern und den Telegrammen ab. Und wenn auf die Abfrage keiner antwortet wird die Eco-Soft auch wohl keine Lust mehr haben weiter zu reden. Oder habe ich irgendwas falsch verstanden.? Gruß Ingo
Ah! Okay, jetzt hats "klick" gemacht! 0x02 ist STX, 0x10 ist DLE, also die Antwort. Dann kann ich ja nun weitermachen :-D
So, das war schonmal recht erfolgreich. - EMS-Verbindung Heizung <-> uC läuft - Verbindung PC(Ecosoft) <-(3964R)-> uC läuft Nun aber wieder ein paar Fragen g. Ich möchte ja nun beides zusammenbringen :) Wenn ich die Kommunikation in der Ecosoft starte sendet diese als erstes "0x00 0x00". Darauf Antworte ich dann mit "0x00 0x00 0x00 0x00 0x53 0x02 0x31". Nun hat die Ecosoft schomal meinen "ServiceKey" identifiziert. Laut dem Log hier aus dem Forum (serial_logamatic_0911_.txt) müsste ich dann noch folgendes an die Ecosoft schicken?! <RX>00 00 01 00 00 00 03 00 01 03 <RX>00 00 02 00 08 0A 0C 0E 10 12 14 16 18 1A 1C 1E Das Abfragen der werte beginnt offenbar ja erst danach: <TX>04 08 07 .. .. ......
TX: 00 00 RX: 00 00 00 00 53 02 31 RX: 00 00 01 00 00 00 03 00 01 03 RX: 00 00 02 00 08 0A 0C 0E 12 14 16 18 1A 1C 1E TX: 04 08 07 RX: 04 08 07 00 0B 01 01 02 00 00 00 00 00 00 00 00 00 00 00 TX: 04 08 02 TX: 04 09 02 RX: 04 08 02 00 48 02 04 4B 02 14 00 00 00 RX: 04 09 02 00 44 02 00 Also ich vestehe dass so dass mit der "00 00" alle Telegrammtypen vom Gateway selber abgerufen werden. Fragt sich nur was passiert wenn man diese Telegramme weglässt. Vielleicht steht ja auch drin welche Busteilnehmer am Bus hängen. Oder muss man bei der EcoSoft vorher angeben welche Busteilnehmer in der Anlage sind? Irgend eine Bedeutung müssen die Werte ja haben. Notfalls einfach mal ausprobieren ob sich die Ecosoft dann anders verhält wenn man andere Werte oder keine Werte schickt. Wenn die "00 00 00" gekommen wäre würde sich die Ecosoft ja nur für die Seriennummer interessieren. Also müsstest Du demnach auch alle Telegramme schicken... Gruß Ingo
Man KANN wohl vorher angeben welche Geräte verbaut sind. Man muss aber nicht. Was ich schonmal gefunden habe: 00 00 00 00 53 02 31 0x53 = ServiceKey, 0x52 = "EcoTool" 0x02 = DEC 2 = Version 2 0x31 = DEC 49 = Version.49 Ich sende da 0x53 0x00 0x63, da meint die EcoSoft dann ich habe einen Servicekey in der Version 0.99 :-) Ich probier da morgen mal weiter!
Hallo an alle, ich habe es endlich geschafft meine Software für die Hardware so langsam in den Griff zu bekommen ;-) Ich möchte eine Platine für meine Hardware fertigen lassen. Darauf befindet sich ein PIC18F2585. Die Hardware soll dann über DIP-Schalter konfiguriert werden können. Je nach Hardwarebestückung und DIP-Schalterstellung gibt es verschieden Modes: 1) nur mitlesen und ausgeben der Telegramme über die serielle Schnittstelle. Ausgabe im Textmodus oder als RAW-Daten mit "0xaa 0x55 0xaa 0x55" anstelle des <Break> was auf dem EMS-Bus. Beim Textmodus wird ein CR&LF gesendet damit nur ein Telegramm in einer Zeile steht. 2) mitlesen und senden. Dazu würden dann zwei Platinen benötigt und die Kommunikation läuft über den CAN-Bus. Hat den Vorteil dass man dann später mehrere Module anschließen könnte. Z.B. ein eigenes Display für Fehleranzeige oder alles andere. Ich würde die Platine fertigen lassen. Es gibt auch eine möglichkeit die Platinen schon fertig bestücken zu lassen. Die Platinen gäb es dann zum Selbstkostenpreis+Versand Wer hätte interesse daran. Den Preis müsste ich noch erst in Erfahrung bringen. Dazu wäre ganz interessant welche Möglichkeiten Ihr habt und was Ihr für eine bestückte SMD-Platine ausgeben möchtet oder könntet. Will nichts verdienen... *) Firmwäre brennen *) Platine bestücken/löten (DIP) *) Platine bestücken/löten (SMD) Allerdings ist die Software für den CAN-Bus noch in der Entwicklung und würde die Platinen natürlich erst fertigen lassen wenn die Software fehlerfrei funktioniert. Die Preise für die Bestückung lohnt sich allerdings erst ab einer größeren Menge weil eine einzelne Platine sonst 200€ kosten würde und sinnlos wäre. Wer will kann ja mal dazu hier posten. Wenn es an die Bestellung geht gibt dann hier noch mal eine e-Mail oder URL. Kann allerdings nichts über den Zeitplan sagen. Ist eben nur ein Hobby von mir und habe nicht immer Zeit um daran zu arbieten. Gruß Ingo Die Emulation eines ServicKey wird erst mal nicht funktionieren aber vielleicht auch irgendwann mal damit funktionieren.
Servus Ingo, ja, das klingt gut :-) An einer solchen, möglichst unbestückten Platine hätte ich Interesse. Da ich schon was älter bin und gerne zittere ;-), wäre mir persönlich eine dip Version lieber. Aber ich würde auch bei einem smd Board nicht nein sagen, abhängig vom Preis natürlich. Danke für Deine Mühe und Arbeit und einen guten Rutsch an alle EMS-Bus-Freaks ;-).
Guten Morgen und frohes neues Jahr :) @ingo: Das hört sich interessant an! An der emulation eines Servicekeys arbeite ich ja grad. Das ganze läuft derzeit auf einem Arduino-Klon. Auf EMS-Seite nutze ich einen i2c-UART. Der kann per Registersetting astreine Breaks auf den Bus zaubern :-) Die Kommunikation über 3964R läuft super. Ich habe offenbar noch ein paar Probleme beim Senden auf den EMS-Bus. :-( Die Anmeldung an das System als ServiceKey (Warten auf 0x8B und dann Antwort mit 0x08) funktioniert. Probleme gibt es aber wenn es weitergeht. Die Buderus-Software versucht ja ersteinmal die angeschlossenen Bausteine zu identifizieren (per 0x04 <geräteid> 0x02). Bei den Abfragen bekomme ich aber nur Müll zurück. Worauf muss ich beim Senden achten? >Nach jedem gesendeten Zeichen musst du den Bus auslesen, >um das Echo (dein gesendetes Zeichen) zu verifizieren. Wenn der Bus auf >Low liegt, kann man wohl nicht senden. Ich muss also mit dem Senden warten bis der Bus frei ist. Wie erkenne ich das am besten in der Software? Warten bis ein Break auf dem Bus auftaucht (also ein Abschluss eines Telegramms auf dem Bus) und dann einfach lossenden? Zusatzfrage: Mein Sender läuft derzeit über einen OP der das TX-Signal vom UART invertiert und dann über einen Transitor der eine Z-Diode "durchschaltet". Ist das hier noch "state-of-the-art" oder gibt es besseres?
Fred Granna schrieb: > Die Anmeldung an das System als ServiceKey (Warten auf 0x8B und dann > Antwort mit 0x08) funktioniert. Na das ist vermutlich ein Tippfehler. Antworten müsstest Du auf das Polling vom Servicekey 0x8b mit Der ServiceKey Adresse 0x0B und nicht 0x08 ;o) Fred Granna schrieb: > Probleme gibt es aber wenn es weitergeht. Die Buderus-Software versucht > ja ersteinmal die angeschlossenen Bausteine zu identifizieren (per 0x04 > <geräteid> 0x02). Bei den Abfragen bekomme ich aber nur Müll zurück. Wichtig wäre zu wissen was Du bekommst und was Du sendest. Vermute mal dass Du auf das Polling 0x8b mit 0x0b beantwortest und dann das Telegramm schickst. Das ist meiner Meinung nach falsch. Der Busmaster 0x08 sendet das Polling und übergibt somit die Kontrolle jeweils einem einzigen Slave mit der Adresse. Und wartet eine bestimmte Zeit. Wenn nichts kommt existiert der Busteilnehmer nicht und wird erst mal für eine Zeit nicht mehr abgefragt. Wenn der Busteilnehmer beim nächsten mal abgefragt bekommt er die Adresse des Slave zurück. Der Busmaster weiss jetzt dass der Busteilnehmer vorhanden ist und und fragt den Busteilnehmer jetzt viel öfter ab. Wenn der Slave Daten zum senden hat antwortet er wieder mit der eigenen Adresse. Dann sendet er die Zieladresse. Es gibt dann folgende drei Möglichkeiten für eine Zieladresse: 1) 0x00 ... Telegramm ist an alle gerichtet er will keine Antwort. 2) <Busadresse> (z.B. 0x08) ... Telegramm ist an einen einzigen Empfänger gerichtet und keine Antwort erwartet. 3) <Busadresse + 0x80) ... Telegramm ist an einen einzigen Empfänger gerichtet und eine Antwort wird erwartet. Danach wird dann die Telegrammadresse gesendet. Wenn der Slave jetzt Daten mitsendet folgen diese. Das erste Byte ist dann das Offset des Telegramms. und danach folgen die Daten mit der Prüfsumme. Wenn der Slave seine Kontrolle über den Bus abgibt weil alle Telegramme gesendet wurden sendet er anschließend noch ein <Break> Dann geht das Polling weiter bis zum anderen Busteilnehmer. Dieser kann dann antworten. Es kann auch sein dass der Busteilnehmer auch erst später antwortet und nicht sofort auf das nächste Polling mit der Antwort reagiert. Also in Deinem Fall würde ich erst mal folgendes Versuchen: RX: 0x8b <Break> TX: 0x0b <Break> . . . RX: 0x8b <Break> TX: 0x0b 0x88 0x02 0x00 <"CRC"> <Break> TX: 0x0b <Break> . . . Vermutlich kann man auch im ersten Durchgang sofort mit dem Telgramm antworten und muss nicht erst mal nur seine Anweseheit zeigen. Weiss leider nicht mehr ob der Busmaster sofort mit dem verstärkten Polling anfängt oder erst drei mal auf eine Antwort vom Busteilnehmer erwartet. Ist schon zu lange her... Wenn das nicht so will wie von mir erwartet würde ich auch mal mit Zieladresse ohne das gesetzte "Antwortbit" versuchen (0x08) Kann auch sein dass man das Offset (0x00) bei einer Abfrage nicht mitsenden muss oder darf. ALso TX: 0x0b 0x08 0x02 0x00 <"CRC"> <Break> TX: 0x0b 0x08 0x02 <"CRC"> <Break> Es kann auch sein dass man nicht wirklich noch zusätzlich mit einer leeren Antwort am Schluss die Übertragung beenden muss und nach einer bestimmten Zeit einfach der nächste Busteilnehmer angepollt wird. Aber wenn mann Pech hat muss man zusätzlich noch irgendwelche Daten übergeben. Habe gerade mal aus meinem Log ohne Polling die folgen Zeilen gefunden: 10 89 29 00 01 90 09 10 29 00 6B DF 10 08 35 00 01 01 00 10 88 14 00 03 6E 08 10 14 00 39 AA 1C EC Meine Vermutung ist aber eher dass z.B. beim ersten Telegramm die RC30 (0x10) die 0x09 auffordert im Telegramm 0x29 mit dem Offset 0x00 das Byte auf 0x01 zu setzen. Wird dann wohl ein Steuerparameter sein. Poste doch einfach mal Deine Versuche und die Antwort. Habe selber noch keine "echten" Sendeversuchen unternommen. Habe nur mal alle Adressen beantwortet um die Service-Key Adresse herauszufinden. Habe Dummerweise erst nach der RC30 angefangen zu suchen und die 0x0b also übersehen. Fred Granna schrieb: > Worauf muss ich beim Senden achten? > >>Nach jedem gesendeten Zeichen musst du den Bus auslesen, >>um das Echo (dein gesendetes Zeichen) zu verifizieren. Wenn der Bus auf >>Low liegt, kann man wohl nicht senden. > > Ich muss also mit dem Senden warten bis der Bus frei ist. Wie erkenne > ich das am besten in der Software? Warten bis ein Break auf dem Bus > auftaucht (also ein Abschluss eines Telegramms auf dem Bus) und dann > einfach lossenden? Ups ich glaube das habe ich schon mit meiner viel zu ausführlichen Antwort erschlagen ;o) Fred Granna schrieb: > Zusatzfrage: Mein Sender läuft derzeit über einen OP der das TX-Signal > vom UART invertiert und dann über einen Transitor der eine Z-Diode > "durchschaltet". Ist das hier noch "state-of-the-art" oder gibt es > besseres? Das war auch die Methode die ich das letzte mal beim scannen der Busadressen verwendet habe. Habe aber danach herausgefunden dass die RC30 und andere "Externe" Busteilnehmer nicht so "brutale" Sendeversuche unternehmen, sondern nur der Busmaster 0x08 und evtl die 0x09 die am "internen" Bus hängen. Beitrag "Re: Logamatic 2107 Schnittstelle" Beitrag "Re: Logamatic 2107 Schnittstelle" Es reicht also eine schaltbare Stromquelle mit ~40mA (wenn ich mich recht erinnere) dafür zu nehmen. Der nächste Versuch ist also bei mir eine Sendestufe bei der der TX-Pin auf die Basis vom NPN-TRansistor geht und einen Emistterwiderstand gegen Masse von 80-100 Ohm. Der Kollektor geht dann direkt mit an den EMS-Bus. Denke das dürfte schon ganz gut gehen. Rudi hat wohl schon sowas ähnliches mit einem FET aufgebaut.... steht irgendwo in diesem Thread ;o) Poste doch mal Deine Versuche und das Ergebnisse... Bin halt neugierig :o) Gruß Ingo
Ui, danke für diese "Ausarbeitung" ;-) Das bedeutet ja, wenn ich das richtig verstehe, das der Busmaster durch das Polling eine Art "Sendefreigabe" weiterreicht. Also muss ich mit dem Senden so lange warten bis der Busmaster mir diese Freigabe per "0x8B <break>" erteilt. Das mit dem TX ohne Z-Diode werd ich auch mal ausprobieren. Sobald das Senden nicht mehr in einem Bus-Chaos endet werd ich berichten ;-)
Fred Granna schrieb: > Das bedeutet ja, wenn ich das richtig verstehe, das der Busmaster durch > das Polling eine Art "Sendefreigabe" weiterreicht. So könnt man das auch formulieren. Mann kann auch in den Telegrammdaten eine längere Pause gesehen. Die RC30 bei mir legt auch mal nach einem Datenhäppchen eine 100ms Pause ein. Fred Granna schrieb: > Sobald das Senden nicht mehr in einem Bus-Chaos endet werd ich berichten > ;-) Ich bin gespannt.... Werde meine Senderversuche erst unternehmen wenn der Empfang und übertragung über CAN-Bus erst mal problemlos läuft. So weit scheint der Weg nicht mehr zu sein :o) Was ich ncoh vergessen habe. Das Telegramm was man sendet muss man zwischen den Bytes eine Pause von einem Byte machen damit der Busmaster dieses Byte wiederholen kann (auf 10 V heruntergezogen). Er spielt also so eine Art Repeater damit auch der in der letzte Reihe auch noch alles mitbekommt. Also genauso wie beim Polling auch. Vielleicht macht es ja Sinn später nach jedem gesendeten Byte die eigenen Daten zu vergleichen. Wenn man irgendwann mal die Schaltung über den EMS-Bus speisen möchte sollte man die Strombelastung gut Buffern damit nicht ausvershen Daten gesendet oder der Bus gestört wird. Gruß Ingo
Hallo Leute, kurze Zwischenfrage zum Thema Sendestufe: Warum groß herum experimentieren, wenn eine original Buderus-Lösung bekannt ist? Beitrag "Re: Logamatic 2107 Schnittstelle" Wenn es etwas gibt, was gegen diese Variante spricht, würde mich das schon interessieren. Gesundes neues Jahr, //niffko
Niffko _ schrieb: > Wenn es etwas gibt, was gegen diese Variante spricht, würde mich das > schon interessieren. Ups, Die Lösung habe ich komplett vergessen :-) Also ich hatte versucht die RC-30 Sendestufe zu entflechten. Ist mir allerdings nicht gelungen (Multilayer Platine) Bin dann zu der gerade geposteten Lösung gekommen. Allerdings ist diese Lösung auch so etwa der selbe Weg.... Bei der Buderus-Lösung sind vier 910 Ohm Wiederstände parallel und haben also einen Gesamtwiderstand von 227 Ohm. Der Bus wird also mit ~60mA belastet. Das wäre auf meine Schaltung übertragen also rechnerisch ein Emitterwiderstand von ~71 Ohm (68 Ohm). Den LM393 habe ich zufällig auch in meiner Schaltung und reinzufällig auch noch eine Hälfte frei. :o) Spricht also nichts dagegen diese zu übernehmen. Der OP soll wohl noch dafür sorgen dass man einen saubereren Pegel zur Ansteuerung hat. DANKE für den Hinweis :o) Die Buderus-Empfangsschaltung muss ich mir irgendwann noch mal genauer ansehen. Vermutlich wird die besser sein... Noch mal zu dem Senden auf dem EMS-Bus. Habe gerade noch mal im Log mit Polling einen kleinen Ausschnitt gesehen dass die RC30 bei mir erst das Telegramm sendet und dannach dann eine leere Antwort. (0x10 <Break>) Also beendet die RC30 Ihre Buskontrolle mit einem eigenen leeren Telegramm am Ende. Gruß Ingo
Fred Granna schrieb: > Ich muss also mit dem Senden warten bis der Bus frei ist. Wie erkenne > ich das am besten in der Software? Warten bis ein Break auf dem Bus > auftaucht (also ein Abschluss eines Telegramms auf dem Bus) und dann > einfach lossenden? Wenn du ein Zeichen sendest wird dieses Zeichen vom Master wiederholt, danach kannst du das nächste Zeichen senden oder eben ein Break für die Busfreigabe von deiner Seite. Das sollte in etwa so aussehen: RX: 8B BRK TX: 08 RX: 08 TX: Zeichen RX: Zeichen .... TX: BRK RX: BRK Grüße.
Rudi schrieb: > Wenn du ein Zeichen sendest wird dieses Zeichen vom Master wiederholt... Stimmt.. ist wohl in der Textflut untergegangen :) Ingo F. schrieb: > Das Telegramm was man sendet muss man zwischen den Bytes eine Pause...
Rudi schrieb: > Wenn du ein Zeichen sendest wird dieses Zeichen vom Master wiederholt, > danach kannst du das nächste Zeichen senden oder eben ein Break für die > Busfreigabe von deiner Seite. ... ist Dir bekannt wie groß der Zeitraum zwischen einem Echo und dem nächsten gesendeten Byte sein darf, bevor das Ganze in's Timeout rennt? //Niffko
Angehängte Dateien:
-
Timeout.png
2,5 KB
Niffko _ schrieb: > ... ist Dir bekannt wie groß der Zeitraum zwischen einem Echo und dem > nächsten gesendeten Byte sein darf, bevor das Ganze in's Timeout rennt? Pausen von 100ms nach der ersten Antwort mit der eigenen Adresse sind kein Problem: Beitrag "Re: Logamatic 2107 Schnittstelle" (Bild1) Also Pausen von 190ms gibt es mehrere, 200ms habe ich noch keine gesehen. Bei mir jeweils bei der RC30 die solche Pausen einlegt.
Ingo F. schrieb: > Pausen von 100ms nach der ersten Antwort mit der eigenen Adresse sind > kein Problem: ja, danke ... dann werde ich wohl auch einfach mit einem 1 Byte + x Delay senden, anstatt extra den Bus zu überwachen. //Niffko
Gesundes neues Jahr erstmal ;-) Niffko _ schrieb: > ja, danke ... dann werde ich wohl auch einfach mit einem 1 Byte + x > Delay senden, anstatt extra den Bus zu überwachen. Besser wäre senden und auf RX warten mit einem Timeout. Wenn das empfangene Byte nicht identisch zum gesendeten Byte ist, musst du auf das nächste 0x8b BRK warten, ansonsten kann die Anlage in eine Störung gehen -> keine Heizung ;-). Ein Delay wäre dann nicht mehr notwendig und mit einem RX-Timeout wärst du auch gleich schneller beim Senden, da der Master in der Regel relativ schnell antwortet.
Rudi schrieb: > Besser wäre senden und auf RX warten mit einem Timeout. Hmm ... da stehe ich jetzt etwas auf dem Schlauch. Also, ich sende ein Byte, der Master repeatet und bevor ich das nächste Byte sende, warte ich auf ... was? Könntest Du mich da noch mal erhellen? Rudi schrieb: > ... ansonsten kann die Anlage in eine Störung > gehen -> keine Heizung ;-). ... glaube ich nicht, das würde die CRC dann schon richten. //Niffko
Niffko _ schrieb: > ja, danke ... dann werde ich wohl auch einfach mit einem 1 Byte + x So groß muss das Timeout ja nicht sein. Meistens kommt die Antwort ohne Pause oder unter einer Bitlänge. Zwei Bit reicht immer. Mann müsste einfach sofort das Byte einlesen und vergleichen. Das ist vermutlich einfacher als ein Delay. Bei einem Fehler sofort mit Break abbrechen und nochmal neu senden. Denke das dürfte kein Problem sein. Ab und zu senden die Busteilnehmer ja auch zwei Telegramme hintereinander. Meine RC30 habe ich schon mal im Log dabei erwischt wie sie ein Telegramm widerholt hat :o) Bei einem erneuten Fehler würde ich dann aufs zweite Polling warten. Rudi schrieb: > Besser wäre senden und auf RX warten mit einem Timeout. Na das ist eine gute Idee. Hätte erst mal keins eingebaut.
Niffko _ schrieb: > Hmm ... da stehe ich jetzt etwas auf dem Schlauch. Also, ich sende ein > Byte, der Master repeatet und bevor ich das nächste Byte sende, warte > ich auf ... was? Könntest Du mich da noch mal erhellen? Ups die Antwort hatte ich noch nicht gesehen.. Sicherlich würde es reichen auf 12Bitlängen zu warten. Würde ich aber nur als Notlösung ansehen. Am besten auf die Widerholung warten. Wenn nach zwei Bitlängen keine Antwort kam unterwegs ist dann abbrechen und noch mal neu senden. vermutlich bekommt man aber nicht mit wenn der UART schon ein Bit empfangen hat. Als Timeout wurde ich dann 14 (vielleicht 15) Bitlängen nehmen falls die MC10 mal nichts wiederholen sollte.
Niffko _ schrieb: > und bevor ich das nächste Byte sende, warte > ich auf ... was? Vielleicht noch genauer auf Deine Frage. Wenn der Master wiederholt dann einfach das nächste Byte senden. Rudi meinte das Timeout für den Fall das der Master nicht antwortet. Gruß Ingo
IngoF schrieb: > Rudi meinte das Timeout für den Fall > das der Master nicht antwortet. Ah jetzt ja ... das war der entscheidende Hinweis, danke. Wobei es bei mir nicht so tragisch wäre, wenn ein Telegramm mal nicht ankommt, da ich sie für die Leistungssteuerung eh' periodisch versende. //Niffko
Angehängte Dateien:
-
RX_EMS.png
84 KB
Hallo Leute, nachfolgend mal meine Variante des RX-Zweiges als Anregung für eigene Lösungen. Die Grundidee ist, zur Signalgewinnung den internen Analog Comparator eines AVR's zu nutzen und diesen dann mit einer Soft-UART mit FIFO zu verheiraten. Letzteres stellt in sofern kein Problem dar, da es Soft-UART Lösungen gibt, die über Input Capture eines Timers getriggert werden und der Ausgang des Analog Comparators so konfiguriert werden kann, dass er besagten Input Capture auslöst. Die Vorteile liegen auf der Hand: der externe Comparator entfällt und man hat den Hard-UART für die Kommunikation mit dem PC frei. Da man zur Erzeugung eines Breaks eh' Hand anlegen muss, ist so ein Soft-UART diesbezüglich auch nicht gerade unpraktisch. Externe Beschaltung siehe Anhang. Empfehlenswerter Soft-UART mit FIFO: Beitrag "Software UART mit FIFO" //Niffko
Niffko _ schrieb: >> ... ansonsten kann die Anlage in eine Störung >> gehen -> keine Heizung ;-). > ... glaube ich nicht, das würde die CRC dann schon richten. Jein, wenn du die anderen Teilnehmer zu oft störst, werden diese einfach abgemeldet und die Anlage geht auf Störung, wenn z.B. der Brenner verschwunden ist. Aus diesem Grund muss auch jedes z.B. 0x8B BRK beantwortet werden. Die genaue Anzahl der tolerierten Fehler kenne ich nicht, müsste man mal austesten. Niffko _ schrieb: > Da man zur > Erzeugung eines Breaks eh' Hand anlegen muss, ist so ein Soft-UART > diesbezüglich auch nicht gerade unpraktisch. Externe Beschaltung siehe > Anhang. Damit verbaust du dir eine Entkopplung von E-Heizungskreis und E-Hausnetz. Ich würde die Konvertierung von den "analogen" Signalen auf digitale Signale so einfach wie möglich halten, sprich über eine passive Schaltung. Ein weiterer Nachteil einer Soft-Uart ist die extreme CPU-Last, da jede Flanke/jedes Bit vergoldet wird. Grüße.
Niffko _ schrieb: > nachfolgend mal meine Variante des RX-Zweiges als Anregung für eigene > Lösungen. Eigentlich auch eine gute Lösung. Allerdings ist mir ein externer Komperator doch irgendwie lieber. Und sooo viel kostet der auch nicht. Sieht gefährlich aus. Würde den Gleichrichter als Verpolschutz dringend wieder reinnehmen. Wenn der Bus verpolt angeschlossen wird gibt es zwei Probleme: 1) Der Komperator funktioniert nicht wie gewünscht. 2) Die BAT46 schließt den EMS-Bus kurz. Habe keine Ahnung was die BAT46 soll. Vermute mal dass sie die Schaltung vor Überspannungen vom EMS-Bus schützen soll.
Angehängte Dateien:
-
delete.png
33 KB
Ich habe mir jetzt nochmal einige unbekannte Werte vom EMS-Bus angesehen. Erkennt jemand den Zusammenhang von Nachricht: 08 00 19 Index 13 und der Brennerleistung 08 00 18 Index 8 ? Anbei ein Plot der beiden Werte.
Hi Rudi, das sieht mir nach der Modulation der internen Gerätepumpe aus. Wird in Prozent angegeben, bezieht sich auf die Drehzahl und wird abhängig von der Brennerleistung variiert. Wenn ich mich richtig erinnere ist die minimale Pumpenmodulation bei deinem Gerät 55% - sollte also passen. //Niffko
Rudi schrieb: > Jein, wenn du die anderen Teilnehmer zu oft störst, ok ... stattgegeben. > ... werden diese einfach abgemeldet und die Anlage geht auf Störung, Was wiederum nicht so tragisch wäre. Kommunikationsfehler generieren im EMS-System nur blockierende Störungen, keine verriegelnden. D.h. die Anlage geht nach Wiederherstellung der Kommunikation wieder in Betrieb. Hilft natürlich nicht wenn die Störungen im Minutentakt auftreten ... schon klar. > Aus diesem Grund muss auch jedes z.B. 0x8B BRK beantwortet werden. hmm ... 0x8B wird bei mir definitiv nicht beantwortet. > Damit verbaust du dir eine Entkopplung von E-Heizungskreis und > E-Hausnetz. Ich würde die Konvertierung von den "analogen" Signalen auf > digitale Signale so einfach wie möglich halten, sprich über eine passive > Schaltung. Wobei letzteres aufgrund der geringen Strombelastbarkeit ja offensichtlich nicht so einfach ist. Mal abgesehen davon, dass in meinem Fall eine Trennung nicht notwendig ist (Heizungsregelung), was spricht dagegen, den Sklaven in das Heizungsnetz zu integrieren und von ihm aus entkoppelt zu kommunizieren? > Ein weiterer Nachteil einer Soft-Uart ist die extreme CPU-Last, da jede > Flanke/jedes Bit vergoldet wird. Hast' ja prinzipiell recht, wird aber durch einen interrupt-beschickten FIFO schon deutlich entschärft. Außerdem läuft man dann nicht Gefahr, dass der AVR beim Empfangen und Weiterleiten der 9600baud Daten, an Langeweile stirbt. IngoF schrieb: > Sieht gefährlich aus. Würde den Gleichrichter als Verpolschutz dringend > wieder reinnehmen. Komm schon ... Du machst hier mit Mikrocontrollern rum und willst mir erzählen, dass du die Polarität von zwei Leitungen nicht vor dem Anschließen feststellen kannst. Wenn Buderus Brückengleichrichter einbaut, dann deshalb, weil die Verdrahtung von Heizungsbauern vorgenommen wird ... wenn Du weißt was ich meine. //Niffko
Niffko _ schrieb: > hmm ... 0x8B wird bei mir definitiv nicht beantwortet. OK... dann aber eben dass Polling für das Modul dass Du emulieren möchtest. Wenn Du Das Polling nicht beantwortest wird diese Adresse viel seltener gepollt und musst länger auf das versenden der Nachrticht warten. Vielleicht ignoriert auch die MC10 Telegramme die von einem "unbekannten" Busteilnehmer kommen. Niffko _ schrieb: > ... dass du die Polarität von zwei Leitungen nicht vor dem > Anschließen feststellen kannst. Sicher bin ich dazu fahig. Macht aber die Sache einfacher mit Gleichrichter. Anstöpseln und fertig. Dann würde ich jedenfalls die Diode entfernen die den Bus kurzschließt wenn man verpolt.
IngoF schrieb: > OK... dann aber eben dass Polling für das Modul dass Du emulieren > möchtest. Wenn Du Das Polling nicht beantwortest wird diese Adresse viel > seltener gepollt und musst länger auf das versenden der Nachrticht > warten. ja, weiß ich doch. Hatte bloß in Rudis Text das 0x8B im Kontext mit Brenner gelesen und dann hätte es bei mir auch als Antwort auftauchen müssen. > Dann würde ich jedenfalls die Diode entfernen die den Bus kurzschließt > wenn man verpolt. Nö, die bleibt drin ;-). Scheint als schnelle Clamp-Diode gegen negative Spikes gedacht zu sein. Ich denke hier muss der jeweilige Anwendungsfall betrachtet werden. Wenn das Interface ständig an- und abgestöpselt wird, kann man sicherlich über einen Brückengleichrichter reden. In meinem Fall wird einmal angeschlossen und gut is'. Deshalb hatte ich in meinem Post auch extra geschrieben: "als Anregung für eigene Lösungen". //Niffko
Niffko _ schrieb: > das sieht mir nach der Modulation der internen Gerätepumpe aus. @Rudi Habe jetzt bei mir noch mal Telegramm und Monitorwert verglichen - es ist die Pumpenmodulation. Bin mir aber fast sicher, dass der Wert bei Dir (GB152) nicht im Monitor angezeigt wird. //Niffko
Dieses "BusEcho" lässt mir ja irgendwie keine Ruhe. Warum existiert dieses Echo nur wenn man über die Servicekey-Schnittstelle etwas sendet? Ich habe dieses Echo noch nicht einmal bei anderen Stationen gesehen. Oder täuscht mich das? Ich habe folgende Komponenten: MC10 Master-Controller (0x08) (UBA3) (Also die "Backplane" des Systems und Busmaster) BC25 Basis-Controller (0x09) RC35 Raum-Controller (0x10) Wenn z.B. nun 0x10 an 0x09 irgendwelche Daten sendet dann sehe ich das genau ein einziges mal. Keine Wiederholungen vom MC10. In den Buderus Planungsunterlagen für EMS ist ein Busdiagram. Im Zentrum steht der MC10 als Master. Von dort sieht man einen EMS-Baum wo die ganzen Zusatzmodule wie RC35, RC25, EM10, MM10 etc angeschlossen sind. Und daneben, einen einzigen dedizierten EMS-Zweig wo nur das BC10/25 angeschlossen ist. Und an diesen Modulen hängt ja der ServiceKey. Meine Vermutung wäre nun das das BC10/25 als Repeater/Gateway zum Internen EMS-Bus auftritt und diese "Echos" nur auf die ServiceKey-Kommunikation zutrifft. Die Echos werden also möglicherweise nicht vom BusMaster generiert sondern vom BasisController BC10/25. Könnte das wer bestätigen? Habt ihr diese "Echos" auch von anderen Modulen?
Fred Granna schrieb: > Wenn z.B. nun 0x10 an 0x09 irgendwelche Daten sendet dann sehe ich das > genau ein einziges mal. Keine Wiederholungen vom MC10. Die Daten die Du siehst sind die Wiederholungen. Wiederholt wird Byte für Byte. Die Telegramme die direkt von den Modulen kommen wirst Du nicht sehen können, da diese mit deutlich geringerer Amplitude senden. Fred Granna schrieb: > Meine Vermutung wäre nun das das BC10/25 als Repeater/Gateway zum > Internen EMS-Bus auftritt ... Ein klares Jain. Ich habe bereits die Interna von BC10, UBA und MC10 in Augenschein nehmen können - die dicken Transistoren hängen nur bei UBA und MC10 am Bus. Beim BC25 sieht die Sache aber anders aus, in ihm sind sozusagen BC10 und UBA vereint. //Niffko
Niffko _ schrieb: > Habe jetzt bei mir noch mal Telegramm und Monitorwert verglichen - es > ist die Pumpenmodulation. Bin mir aber fast sicher, dass der Wert bei > Dir (GB152) nicht im Monitor angezeigt wird. Danke! Im Monitor wird der Wert nicht angezeigt. Fred Granna schrieb: > Und daneben, einen einzigen dedizierten EMS-Zweig wo nur das BC10/25 > angeschlossen ist. Richtig, der ServiceKey bekommt noch 12V VCC, also ein 3-Draht-Bus und kein 2-Draht-Bus. > Meine Vermutung wäre nun das das BC10/25 als Repeater/Gateway zum > Internen EMS-Bus auftritt und diese "Echos" nur auf die > ServiceKey-Kommunikation zutrifft. Die Echos werden also möglicherweise > nicht vom BusMaster generiert sondern vom BasisController BC10/25. Nein, wie ich weiter oben schon geschrieben hatte: Der Klinkenstecker hängt mit den 2 Leitungen (GND,DATA) direkt am internen EMS-Bus. Fred Granna schrieb: > Wenn z.B. nun 0x10 an 0x09 irgendwelche Daten sendet dann sehe ich das > genau ein einziges mal. Keine Wiederholungen vom MC10. Du siehst die Wiederholung. Als TX-Slave arbeitet das ganze als Stromschnittstelle und als RX-Slave Level-Sensitiv. Dreh mal dein Oszi. auf dann siehst du es.
Niffko _ schrieb: >> Wenn z.B. nun 0x10 an 0x09 irgendwelche Daten sendet dann sehe ich das >> genau ein einziges mal. Keine Wiederholungen vom MC10. > Die Daten die Du siehst sind die Wiederholungen. Wiederholt wird Byte > für Byte. Die Telegramme die direkt von den Modulen kommen wirst Du > nicht sehen können, da diese mit deutlich geringerer Amplitude senden. Das würde ja bedeuten, das wenn ich zu heftig in den Bus schreie, die anderen Module alle Zeichen doppelt empfangen und daher nur Müll zurückkommt? Das würde evtl. erklären warum meine Antworten auf das Polling "0x8B" funktionieren, die Kommunikation mit anderen Modulen aber nicht.
Fred Granna schrieb: > ... dass wenn ich zu heftig in den Bus schreie ... ich denke, dein 'Umgangston' würde sich, durch den Austausch der Z-Diode in Deiner Senderstufe gegen einen 220R Widerstand, erheblich verbessern ;-) //Niffko
Niffko _ schrieb: > .....durch den Austausch der Z-Diode > in Deiner Senderstufe gegen einen 220R Widerstand..... Ja, das wird es garantiert ändern. Hoffe Ihr könnt mir noch mal verzeihen wenn ich schon wieder den Link bringe: Beitrag "Re: Logamatic 2107 Schnittstelle" Auf dem ersten Bild kann man gut das Polling von der MC10 an die RC30 sehen. Die MC10 brüllt rum und dann ein kleines flüstern von der RC30 das dann die RC30 noch mal in den letzten Winkel brüllt. Der Rest der Antwort kommt dannn von der RC30 nach etwa 100ms wenn sich die RC30 wieder gesammelt hat. Was dann genauso wie auch das Break widerholt wird. Wenn man eine zu kleine Z-Diode nimmt und die Spannung noch tiefer als die MC10 herunter zieht gibt es teilweise richtige Ausfälle am Bus Bei der nach dem Break noch ein 0xFE gesendet wird. Ob das jetzt eine Absichtliche Fehlermeldung oder eine Fehlfunktion kann ich nicht beurteilen. Gruß Ingo
IngoF schrieb: > Hoffe Ihr könnt mir noch mal verzeihen wenn ich schon wieder den Link > bringe: Dann darf ich aber auch mal ;-) Beitrag "Re: Logamatic 2107 Schnittstelle"
Okay, also vereinfacht gesagt: Keiner Spricht direkt sondern immer über den Chef. Jeder flüstert dem Chef was zu wenn er dran ist (Aufforderung kommt vom Chef) und der wiederholt das Laut so das es dann alle hören.
Rudi schrieb: > Dann darf ich aber auch mal ;-) Tja, der Thread ist ja schon etwas länger... Da kann man noch viel ausgraben was inzwischen schon fast untergegangen ist. Fred Granna schrieb: > Könnte das wer bestätigen? Habt ihr diese "Echos" auch von anderen > Modulen? Wenn man nicht mit einem Oszilloskop auf dem Bus hängt ist es auch nicht soo leicht dies mit zu bekommen. Das Problem ist dass der größte Teil von der Adresse 0x08 kommt und die MC10 sich selber natürlich nciht widerholt. Wenn das jemand selber nachvollziehen möchte kann am besten am Oszilloskop die Triggerschwelle knapp über die Maximale Spannung stellen und triggert dann auf das Überschwingen. So jetzt werde ich mal lieber wieder an meiner Software spielen und versuchen mich hier zurück zu halten.
Ich peil es nich. Kann mir kurz einer schildern was für z.B. senden muss um z.B. eine Versionsabfrage an ein Modul zu richten?
Fred Granna schrieb: > Ich peil es nich. Kann mir kurz einer schildern was für z.B. senden muss > um z.B. eine Versionsabfrage an ein Modul zu richten? 0x0B 0x10 0x02 <CRC> Ansonsten schalte deine Anlage aus/ein und schau dir die ersten Nachrichten an.
Rudi schrieb: > Ansonsten schalte deine Anlage aus/ein und schau dir die ersten > Nachrichten an. Hm, darauf hät ich auch kommen können facepalm bzgl. Sendepfad: Ich hab mir nun das hier zum Vorbild genommen: Beitrag "Re: Logamatic 2107 Schnittstelle" Ich invertiere mein UART-TX über nen OpAMP und denn auf einen Transistor der zieht den Bus über 220 Ohm auf Masse. Zwei Fragen dazu: - Wozu ist der 4K7 PUllup dort? - Ist der 1,5n Kondensator wichtig?
Fred Granna schrieb: > Zwei Fragen dazu: > - Wozu ist der 4K7 PUllup dort? Damit der Transistor einen ordentlichen Pegel sieht, falls mal nichts passiert oder der OP nicht beschaltet ist (dauersenden). > - Ist der 1,5n Kondensator wichtig? Rechnen das mal durch (Tiefpass), siehe: http://de.wikipedia.org/wiki/RC-Glied
Angehängte Dateien:
-
tiefpass_tx.png
2,3 KB
Die Kurve für den Tiefpass sieht in etwa so aus. Ich denke die hohen Frequenzen der Anlage (CPU etc.) sollen sich nicht durch das ganze Haus verteilen ;-)
Hm, ich glaub meine CRC-Berechnung haut nicht hin. Habe diese Funktione hier genommen: Beitrag "Re: Logamatic 2107 Schnittstelle" Und dann mal probiert: uint8_t tempbuffer[]={0x10,0x21,0xac,0x0,0x0,0x0,0x0}; uint8_t crc=buderus_ems_crc(tempbuffer,7); da bekomme ich als CRC: 0x0D Laut dem hier müsste es aber 0x1A sein oder? Beitrag "Re: Logamatic 2107 Schnittstelle"
Fred Granna schrieb: > Hm, ich glaub meine CRC-Berechnung haut nicht hin. Und ich weiss das sie funktioniert ;-) Versuch mal Länge 8 und nicht 7. Die Berechnung geht von der Datenlänge mit CRC aus.
Jo, hab ich auch zur sekunde festgestellt. Bekomme aber trotzdem keine Antworten... Befürchte das da mit dem Timing was nicht hinhaut. Denke mal mit meinem i2c-UART am EMS-Bus kann ich das ganze vergessen. Hat hier einer von euch spezis nen bissl C-Code zum durchforsten für mich? Ihr seit doch da bestimmt schon weiter als ich...
Moin, hat eigentlich schon jemand eine richtige Abfrage auf den EMS-Bus gemacht? Ich meine jetzt nicht einfach ein Byte auf eine Pollinganfrage senden :)
Mal ein paar Tests: Ich warte jeweils auf "0x8B <brk>". Nach meinen Telegrammen sende ich jeweils "0x08 <brk>" zum Abschluss Ich sende "0xB 0x8 0x2 0x3E <brk>" und bekomme "80 0B <brk>". Ich sende "0xB 0x8 0x2 0x00 0x3E <brk>" und bekomme "80 0B <brk>" Ich sende "0xB 0x8 0x2 0x3E <brk>" und bekomme "80 0B <brk>". Ich sende "0xB 0x8 0x0 <brk>" und bekomme "80 0B <brk>". Ich sende "0xB 0x8 <brk>" und bekomme "80 0B <brk>".
Ich sende "0B 88 02 00 06 9A" Ich bekomme "08 0B 02 00 7B 04 05 00 00 00 FC 00" uff O.O Warum geht das? Was bedeutet die 0x06 vorm CRC?
Fred Granna schrieb: > Warum geht das? Wie schon einmal gesagt, schalte deine Anlage aus/ein und schau dir die initialen Nachrichten an ......... > Was bedeutet die 0x06 vorm CRC? K.A., evtl ein Index. Was hängt denn bei dir an Adresse 0x08 und mit welcher Version ?
Rudi schrieb: > Was hängt denn bei dir an Adresse 0x08 und mit welcher Version ? Das ist UBA4, Version 4.5. Die Version sieht man ja im Telegram.
Fred Granna schrieb: > Ich sende "0B 88 02 00 06 9A" > Ich bekomme "08 0B 02 00 7B 04 05 00 00 00 FC 00" Gratuliere! Darf ich fragen, mit welchem Prozedere du sendest - ich meine im Speziellen die Pausen zwischen den Bytes? //Niffko
Fred Granna schrieb: >> Was hängt denn bei dir an Adresse 0x08 und mit welcher Version ? > > Das ist UBA4, Version 4.5. Die Version sieht man ja im Telegram. Das sehe ich. Mich wundert nur die Länge der Antwort. Bei mir sieht es so aus wenn die 0x10 anfragt: 10 88 02 00 06 33 08 10 02 00 40 03 02 3d
Niffko _ schrieb: > Darf ich fragen, mit welchem Prozedere du sendest - ich meine im > Speziellen die Pausen zwischen den Bytes? Nach jedem Byte hole ich mir die Antwort. Also ich sende nicht weiter bis ich das "echo" vom Master habe.
Fred Granna schrieb: > Nach jedem Byte hole ich mir die Antwort. Also ich sende nicht weiter > bis ich das "echo" vom Master habe. Joa ... danke! Rudi schrieb: > Mich wundert nur die Länge der Antwort. Bei mir sieht es > so aus wenn die 0x10 anfragt: > > 10 88 02 00 06 33 > 08 10 02 00 40 03 02 3d Bei mir sieht's so aus (UBA3 V2.07): 10 88 02 00 09 3C 08 10 02 00 40 02 07 3A UBA3 und UBA4 haben technisch gesehen nicht mehr viel gemein, daher evtl. die unterschiedlichen Antworten. //Niffko
Mich würde ja interessieren was der ServiceKey intern so alles anstellt. - Der Servicekey empfängt die Anfrage "04 08 02" -- Der Key sendet auf dem Bus "0B 88 02 00 06 <crc> <brk>" -- Der Key empfängt vom Bus "08 0B 02 00 7B 04 05 00 00 00 <crc> <brk>" - Der Key sendet zur Software "04 08 02 00 7B 04 05 00 00 00". Man bräuchte mal einen parallelen Log vom ServiceKey und vom EMS-Bus um mal zu sehen was da wie angestellt wird...
Fred Granna schrieb: > Mich würde ja interessieren was der ServiceKey intern so alles anstellt. Also zumindest packt er auch mehrere Teiltelegramme zusammen oder splittet die. Das Telegramm 0x3f besteht beim Service-Key aus etwa 100 Byte. Auf dem EMS-Bus sind die gesplittet und haben nach dem Telegrammtyp das Offset. Die Logamatic fragt ja erst mal alle Telegramme der Busteilnehmer ab. Dannach kommen nur noch geänderte Werte mit einem 0x20 noch vor der 04. Mich würde auch mal ein paralleles Log interessieren. Nur bräuchte irgendjemand einen Service-Key und gleichzeitig eine Möglichkeit die Daten aufzuzeichenen. Für das Log würde es ja auch reichen wenn man dies mit einem Programm wie hTerm z.B. Hexadezimal evtl mit dem Zeitstempel mitloggt. Eigentlich muss mann nicht unbedingt eine großartige Empfangsschaltung haben. Es reicht aus Die Masse (Pin 5) von der Seriellen Schnittstell auf die 12 Volt von der Service-Key Buchse zu gehen und die Daten auf die Empfangsleitung der Schnittstelle (Pin 3). Oder umgekehrt. Am besten mit einem Laptop das keine Verbindung zum Stromnetz hat. Habe das damals auch gemacht und keine Probleme damit gehabt. Dadurch hat man dann einen Signalpegel von +-2,5Volt. Eigentlich benötigt man mindestens +-3 bis +-12Volt als Pegel. Hat bei mir aber einwandfrei funktioniert. Was dies 0x00 0x06 soll interesssiert mich auch. Eigentlich wäre das Offset 0 mit den Daten 0x06. Es gibt auch viele Telegramme von der RC30 (0x10, 0x11) die auch irgendwelche Daten an die MC10 senden. Vermute mal das sind irgendwelche Parameter/Stellwerte für die Heizungsregelung. Hatte bei mir gestern schon mal das simple beantworten der 0x8b mit 0xb programmiert und werde dann in der nächsten Zeit endlich auch mal "echte" Sendeversuche unternehmen können wenn ich dazu Zeit finde. Gruß Ingo
IngoF schrieb: > Auf dem EMS-Bus sind die gesplittet und haben nach dem Telegrammtyp das > Offset. > > Die Logamatic fragt ja erst mal alle Telegramme der Busteilnehmer ab. > Dannach kommen nur noch geänderte Werte mit einem 0x20 noch vor der 04. Und das ist genau die Frage! Fragt der wirklich AKTIV in den Bus oder hat der Key intern "nur" einen Puffer in dem die Telegramme "<gerät> 0x00 <telegramtyp> ..." die so über den Bus schwirren eingelagert und dann daraus geholt werden? Ich glaube ohne "Doppellog" kommt man da wirklich nicht weiter. Ich habe vorhin mit dem Offset vor der CRC ein wenig gespielt; die Heizung hat dann plötzlich nen Fehler ausgegeben...
Fred Granna schrieb: > Ich glaube ohne "Doppellog" kommt man da wirklich nicht weiter. Ich habe Das stimmt. Ohne Log geht garnichts. Würde aber vermuten dass der ServiceKey alles im Speicher vom anfang an mitpuffert und dann nur noch Änderungen überwacht und diese dann über die serielle Schnittstelle mitsendet. Vielleicht werden ja auch mal am Anfag alle Telegramme abgefragt ohne dass sich die Logasoft dies anfragt. Und wenn eine Anfrage auf ein spezielles Telegramm kommt aus dem Speicher sendet. Vielleicht hängt das auch vom Telegrammtyp ab wie er sich verhält.... Wollte ja eigentlich auch nur sagen dass ein Log auch jeder ziehen kann der eine zweite serielle Schnittstelle frei hat und sich nur ein Kabel RS232 auf Klinke basteln muss. (1x Service-Key und 1x Diagnose-Buchse) Vermute mal dass jemand der einen ServiceKey hat sich nicht noch extra irgend eine Schaltung zusammenlötet oder sogar irgendwas programmiert..
Also wir haben jetzt bei einem Telegramm schon mehrere Möglichkeiten: UBA3 V3.2 --------- 10 88 02 00 06 33 08 10 02 00 40 03 02 3d UBA3 V2.7 --------- 10 88 02 00 09 3C 08 10 02 00 40 02 07 3A UBA4 V4.5 / keine Erweiterung ----------------------------- 0B 88 02 00 06 9A 08 0B 02 00 7B 04 05 00 00 00 FC UBAX V 2.4 / SAFE 2.20 / keine Erweiterung ------------------------------------------ TX: 04 08 02 RX: 04 08 02 00 48 02 04 4B 02 14 00 00 00 Die letzten 3 0x00 deuten auf eine fehlende Erweiterung hin !?
Also mit dem Offset einfach so herumexperimentieren werde ich mich erst mal nicht trauen :-) Wer weiss denn schon was man da so alles verstellen kann... Für mich reicht erst mal wenn ich die Telegramme mitlogge und nur die Schaltzeiten verändern kann. Also dass mein Server dynamisch die Zeiten ändern kann. Z.B. wenn ich schon weiss dass der Arbeitstag länger dauern wird eine eMail an meinen Server schicken und der ändert die Heizzeiten. Vielleicht auch schnell mal für ein Jahr im vorraus meinen Urlaub eintrage und alles automatisch umgestellt wird :o) Und natürlich dass ich sehen kann was meine Heizung denn da so veranstaltet und sich irgendwie Energie einsparen lässt. Gruß Ingo
Fred Granna schrieb: > Und das ist genau die Frage! Fragt der wirklich AKTIV in den Bus oder > hat der Key intern "nur" einen Puffer in dem die Telegramme "<gerät> > 0x00 <telegramtyp> ..." die so über den Bus schwirren eingelagert und > dann daraus geholt werden? Alle Module haben ein EEProm mit festen Daten und volatile Daten (Temperaturen etc.). Wie diese beiden Datentypen unterschieden werden ist nun die große Frage. Der ServiceKey wird sich wohl alle EEProm Daten von den Modulen holen und speichern. Die volatilen Daten bzw. die nicht volatilen Daten die geändert werden (z.B. durch die RC3X) bekommt er direkt vom Bus.
Rudi schrieb: > Die letzten 3 0x00 deuten auf eine fehlende Erweiterung hin !? Das könnte ein Platz für eine weitere Versionsnummer (Erweiterung?) sein. Die MC10 übermittelt ja seine eigene Version und die SAFe-Version. Die Seriennummer scheinen ja immer aus drei Byte sein
1 | RX: 04 08 02 00 H MC10 2.04 48 02 04 4B 02 14 00 00 00 |
2 | K SAFe 2.20 4B 02 14 |
Weiter Probiert mit "Offset"; sehr interessant: "0B 88 02 00 02 <crc> <brk>" => "08 0B 02 00 7B 04 05 93" "0B 88 02 00 03 <crc> <brk>" => "08 0B 02 00 7B 04 05 93" "0B 88 02 00 04 <crc> <brk>" => "08 0B 02 00 7B 04 05 00 3F" "0B 88 02 00 05 <crc> <brk>" => "08 0B 02 00 7B 04 05 00 00 7E" "0B 88 02 00 06 <crc> <brk>" => "08 0B 02 00 7B 04 05 00 00 00 FC" "0B 88 02 00 08 <crc> <brk>" => "08 0B 02 00 7B 04 05 00 00 00 00 00 DB" "0B 88 02 00 10 <crc> <brk>" => "08 0B 02 00 7B 04 05 00 00 00 00 00 00 03 44" Was würdet ihr sagen was dieser "Offset" wirklich ist? ;-)
Rudi schrieb: > Die letzten 3 0x00 deuten auf eine fehlende Erweiterung hin !? Kann es vielleicht sein dass sich die MC10 je nach Absender anders verhält? Beides mal wenn die 0x00 0x00 0x00 auftaucht war die Adresse 0x0b im Spiel. bei der 0x10 sind die nciht aufgetaucht. Die untere UBA wird vermutlich auch eine UBA3 sein. Die Version liegt ja genau in dem Bereich von den anderen beiden UBA. Keine Ahnung ob da was dran ist..
YEAH! "0B 88 18 0 255 <crc>" => "08 0B 18 00 3C 02 77 64 17 09 01 25 40 80 00 02 32 80 00 00 7A FF 2D 48 00 C8 00 02 00 B1 00 0D" :-D
Fred Granna schrieb: > Was würdet ihr sagen was dieser "Offset" wirklich ist? ;-) Die maximale Antwortslänge ;-) 09 88 04 05 01 af 08 09 04 05 19 cb 10 88 04 00 0c 21 08 10 04 00 04 1b 03 40 18 19 30 00 00 69 6b 0c 5d
Mensch so langsam wird das ja konkret. Ich lese so nebenbei mit. Habe schon ein schlechtes Gewissen, weil ich nen Servicekey besitze aber momentan keine Möglichkeit zum mitloggen habe. Mist.
Und jetzt pass auf: "0B 88 18 03 01" => "08 0B 18 03 64 DA" Das ist auslesen eines Registers: 18 = Register 03 = Offset (Start) 01 = Anzahl der Zeichen die gelesen werden Also lese ich aus Register 18 das dritte Zeichen
@Fred Granna Kannst du mal versuchen ob es sich bei dem dritten und vierten Byte um einen Offset in einen statischen Speicher handelt ? 10 88 15 00 05 <crc> 10 88 1c 00 0b <crc> Und dann mal bei der 0x15 schauen ob du die Antwort der 0x1c durch ändern der Längenangabe mit empfängst.
Rudi schrieb: > 10 88 15 00 05 <crc> = 08 0B 15 00 00 3C 01 01 09 <FE> - 10 88 15 00 10 <crc> = 08 0B 15 00 00 3C 01 01 09 48 00 00 <86> > 10 88 1c 00 0b <crc> = 08 0B 1C 00 00 00 00 00 00 00 00 00 00 00 00 <97> Oder hab ich die Frage nicht richtig verstanden?
Fred Granna schrieb: > Was würdet ihr sagen was dieser "Offset" wirklich ist? ;-) IngoF schrieb: > Also mit dem Offset einfach so herumexperimentieren werde ich mich erst > mal nicht trauen :-) Also bei der Seriennummer kann vermutlich nicht viel passieren... Fred Granna schrieb: > Was würdet ihr sagen was dieser "Offset" wirklich ist? ;-) Hey, bitte sagen falls ich hier herumtrolle.... Also das Offset habe ich von einigen Telegrammen wie z.B. das 0x39 das ich gerade mitgeloggt habe und die Daten hinter einander kopiert habe. Wenn mann z.B. beim ersten Telegramm nur die Datenbytes zählt kommt mann auf 26 = 0x1A. Das nächste Telegramm fängt mit 0x1B im "Offset" an. in der Zeile darunter mit dem RX: das Telegramm von Chris_be was ich aus seinen Logs zusammengestellt habe... Ich finde diese beiden Telegramme sehen doch sehr gleich aus.. Ist das nur Zufall?? Allerdings scheint es auch wohl teilweise andere Bedeutungen zu haben. Vielleicht ist das nach Sollwerten, Veränderlichen Daten oder Seriennummern anders. Bei dem Telegramm 0x10 und 0x11 sind das Telegramme von der RC30 an die MC10. vielleicht ist dass dann dort kein Offset und ist vielleicht ein Befehl. Was mich daran stört ist dass die Antwort unterschiedlich lang ausfällt. Dann noch das "Versionsnummernproblem" warum wird da bei einigen die 0x06 und bei anderen 0x09 an das "Offset" 0x00 gesendet??? Ist das ein Befehl, EIne Prüfsumme?? Was soll das? Dort scheint es kein Offset zu sein. Hoffe ich kann mit meinen "Spekulationen" helfen... Gruß Ingo
Fred Granna schrieb: > Oder hab ich die Frage nicht richtig verstanden? Doch, alles okay. Das scheint so nicht zu funktionieren. Es wird wohl wie bei ECO-CAN über Typen gehen, also was du als Register bezeichnest und einen Offset, den es bei ECO-CAN auch gibt.
IngoF schrieb: > Also das Offset habe ich von einigen Telegrammen wie z.B. das 0x39 das > ich gerade mitgeloggt habe und die Daten hinter einander kopiert habe...... Sorry, glatt das wichtigste vergessen.. Hier die dazugehörigen Daten als TXT-Datei:
IngoF schrieb: > Hoffe ich kann mit meinen "Spekulationen" helfen... Es ist ja nicht so das wir die Daten nicht ändern können, es soll nur etwas komfortabler werden ;-). Am besten hält man sich erst einmal an die RC3X, so wie die die Daten ändert. Bisher hat sich leider noch niemand die Mühe gemacht das Protokoll für die Änderungen zu erfassen.
@ingo
Ich habe eben mal eine Zeile aus deinem Log genommen:
{52} 19:49:38 06.01.11: 10 88 11 18 1B 52
{CF} 19:49:38 06.01.11: 08 10 11 18 00 00 00 00 00 00 00 00 00 00 00 00
CF
Habe dann gesendet "11 88 11 18 1B <crc>"
Resultat: "08 0B 11 18 00 00 00 00 00 00 00 00 00 00 00 00 3C"
Dann "11 88 11 18 1C <crc>"
Resultat "08 0B 11 18 00 00 00 00 00 00 00 00 00 00 00 00 3C"
Und "11 88 11 18 05 <crc>"
Resultat "08 0B 11 18 00 00 00 00 00 00 00 00 00 00 00 00 3C"
Und "11 88 11 00 1B <crc>"
Resultat "08 0B 11 00 00 00 00 00 00 00 00 00 00 00 00 00 48 00"
@Fred Granna Hast du deine Anlage nicht programmiert (Heizzeiten) ?
Fred Granna schrieb: > "0B 88 02 00 02 <crc> <brk>" => "08 0B 02 00 7B 04 05 93" > "0B 88 02 00 03 <crc> <brk>" => "08 0B 02 00 7B 04 05 93" > "0B 88 02 00 04 <crc> <brk>" => "08 0B 02 00 7B 04 05 00 3F" > Was würdet ihr sagen was dieser "Offset" wirklich ist? ;-) ALso das Offset meinte ich mit dem dritten Byte was bei Dir immer 0x00 ist. Aber das Byte dannach ist wohl die Antwortlänge. Allerdings scheint die MC10 das nach Belieben anzupassen. Die 0x02 ist der MC10 zu wenig gewesen und hat dann einfach 3 Datenbyte gesendet. Bei den Seriennummer Rudi schrieb: > UBA3 V3.2 > --------- > 10 88 02 00 06 33 > 08 10 02 00 40 03 02 3d > > UBA3 V2.7 > --------- > 10 88 02 00 09 3C > 08 10 02 00 40 02 07 3A Bei den Seriennummern wurden nur 3 Datenbyte gesendet obwohl einmal 6 und einmal 9 Datenbyte abgefragt wurden. Fred Granna schrieb: > 18 = Register > 03 = Offset (Start) > 01 = Anzahl der Zeichen die gelesen werden > > Also lese ich aus Register 18 das dritte Zeichen ALso da bin ich nicht mit zufrieden.. ich stimme für Telegramm 0x18 also die schnell veränderbaren Messwerte. Könnt Ihr denn mal vergelichen ob das mit dem Offset auch wirklich stimmt? Wenn ich richtig verstanden habe sind die Daten die dann gesendet identisch mit den Daten aus dem letzten Telegramm 0x00 ab dem Offset 0x03?? Gruß Ingo Fred Granna schrieb: > Ich habe eben mal eine Zeile aus deinem Log genommen: > {52} 19:49:38 06.01.11: 10 88 11 18 1B 52 > {CF} 19:49:38 06.01.11: 08 10 11 18 00 00 00 00 00 00 00 00 00 00 00 00 > CF > > Habe dann gesendet "11 88 11 18 1B <crc>" > Resultat: "08 0B 11 18 00 00 00 00 00 00 00 00 00 00 00 00 3C" OK. Leider ist ja nicht bekannt was das "Telegramm" 0x10 und 0x11 überhaupt für eine Bedeutung hat. Dass die Prüfsumme ja anders ist liegt an der unterschiedlichen Adresse. Oder habe ich Dich falsch verstanden? Habe hier mal die beiden Telegramm von Chris_be: RX: 04 08 10 00 34 55 02 09 89 0A 12 17 2A 00 BF 4B 34 55 02 09 89 0A 14 12 22 00 1E 4B 33 43 02 1A 86 05 10 1E 18 00 02 4B 36 4C 02 24 80 01 00 01 27 00 01 4B 36 59 01 FE 00 00 00 0F 00 00 01 4B 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 RX: 04 08 11 00 37 41 02 26 8A 02 08 1A 25 00 01 4B 36 4C 02 05 87 0C 0A 14 22 00 01 4B 36 4C 02 05 87 0B 15 11 06 00 01 4B 36 4C 02 05 87 0B 15 07 1C 00 01 4B 36 4C 02 05 87 02 0D 0C 21 00 01 4B Wenn das ja mit dem Offset stimmt wunder mich nur warum dort bei mir alles 0x00 angezeigt wird und bei Crhis_be ganz andere Werte stehen... Muss dann eine andere Hardware sein oder vielleicht sind das irgendwelchen geloggten Werte von der MC10 die erst nach einer bestimmten Laufzeit in diesen "Speicherplätzen" abgelegt werden... Gruß Ingo
Rudi schrieb: > Hast du deine Anlage nicht programmiert (Heizzeiten) ? Doch, aber nur HK1. Die restlichen (WW und Zirkulation) übernehmen diese Einstellung.
Rudi schrieb: > Hast du deine Anlage nicht programmiert (Heizzeiten) ? Also die Heizzeiten sind doch die Telegramme 0x3f soweit ich das mal gesehen habe.. Oder sind das vielleicht die Temperaturen für die Schaltpunkte? Kann ja eigentlich auch nicht sein. es gibt doch nur zwei...
Fred Granna schrieb: > Doch, aber nur HK1. Die restlichen (WW und Zirkulation) übernehmen diese > Einstellung. Also bei mir ist HK1 und die Zirkulation mit einem eigenen Programm versehen. Zirkulation nur morgens zwischen 5:00 und 6:00 soweit ich mich erinnere.
IngoF schrieb: > Habe hier mal die beiden Telegramm von Chris_be: > RX: 04 08 10 00 34 55 02 09 89 0A 12 17 2A 00 BF 4B 34 55 02 09 89 0A 14 > 12 22 00 1E 4B 33 43 02 1A 86 05 10 1E 18 00 02 4B 36 4C 02 24 80 01 00 > 01 27 00 01 4B 36 59 01 FE 00 00 00 0F 00 00 01 4B 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 So sieht das zerteilt aus: 04 08 10 00 34 55 02 09 89 0A 12 17 2A 00 BF 4B 34 55 02 09 89 0A 14 12 22 00 1E 4B 33 43 02 1A 86 05 10 1E 18 00 02 4B 36 4C 02 24 80 01 00 01 27 00 01 4B 36 59 01 FE 00 00 00 0F 00 00 01 4B 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 und > RX: 04 08 11 00 37 41 02 26 8A 02 08 1A 25 00 01 4B 36 4C 02 05 87 0C 0A > 14 22 00 01 4B 36 4C 02 05 87 0B 15 11 06 00 01 4B 36 4C 02 05 87 0B 15 > 07 1C 00 01 4B 36 4C 02 05 87 02 0D 0C 21 00 01 4B 04 08 11 00 37 41 02 26 8A 02 08 1A 25 00 01 4B 36 4C 02 05 87 0C 0A 14 22 00 01 4B 36 4C 02 05 87 0B 15 11 06 00 01 4B 36 4C 02 05 87 0B 15 07 1C 00 01 4B 36 4C 02 05 87 02 0D 0C 21 00 01 4B Ich hab grad weiter oben was zu den Schaltzeiten geschrieben: Ich habe nur Zeiten für HK1 programmiert, die anderen Module übernehmen diese Zeit. Denke mal das wird bei dir genauso sein und daher sind die dann 0x00 ...
Sorry, habe nicht verstanden was Du damit sagen wolltest... Hatte nur meine Einstellungen hier genannt falls hier irgendjemand eine Idee mit der Zuordnung der Daten zu den Schaltzeiten hat.. Hatte Rudi so verstanden dass die 0x00 dort stehen weil Du nur einen HK und sonst keine Zeiten programmiert hast. Wollte nur sagen dass ich für die Zirkulation ein eigenes Zeitprogramm erstellte habe und nicht von dem Heizkreis1 die Zeiten übernommen wurden. Also demnach müssten dann ja bei mir andere Daten auftauchen....
IngoF schrieb: > Also demnach müssten dann ja bei mir andere Daten > auftauchen.... oder besser gesagt mehr Daten... weil ich ja noch zusätzlich ein Schaltprogramm für die Zirkulation eingestellt habe...
Das Ding ist: Die Logs der Kommunikation zwischen ServiceKey und PC helfen nur bedingt. Beispiel: > <TX>04 08 07 (Sendet der PC zum Servicekey) Würde ich nun übersetzen nach "0x0B 0x88 0x07 0x00 0xFF" Das Ergebniss: "08 0B 07 00 0B 01 00 00 00 00 00 00 00 00 00 00 00 FB" > <RX>04 08 07 00 0B 01 02 00 00 00 00 00 00 00 00 00 00 00 (Sendet der SK zum PC) Solche EInzelabfragen sind also wohl kein Problem. Aber es gibt auch solche Anfragen an den ServiceKey: > <TX>04 08 > <TX>04 09 Und da kommen dann 20 Verschiedene Telegramme von 0x08 und 0x09: <RX>04 08 07 00 0B 01 02 00 00 00 00 00 00 00 00 00 00 00 <RX>04 08 18 00 26 01 BF 64 64 19 01 17 01 01 E4 83 00 80 00 02 0F FF 2D 48 00 00 FF 00 00 00 E4 02 82 02 83 73 00 00 2C 00 00 <RX>04 08 19 00 00 59 01 98 02 61 FF FF FF 00 00 BA 78 04 7B 9E 02 EC F8 03 BD D8 00 AB F4 00 00 <RX>04 08 02 00 48 02 04 4B 02 14 00 00 00 usw usw usw.... _Masterfrage_: Wie veranlasse ich die Module ihre kompletten Daten auf einmal auszugeben?
Fred Granna schrieb: > Wie veranlasse ich die Module ihre kompletten Daten auf > einmal auszugeben? Also ich hatte gehofft dass das Telegramm auch auf dem EMS-Bus anwendbar wären... Also: für alle Telegramme die vorhanden sind: 0b 08 <Break> für alle Daten zu dem Telegramm/Datentyp 0x18 0b 08 18 <Break> für die Daten von Telegramm 0x18 0b 08 18 1B <CRC> <Break> für die 10 Bytes ab Adresse 0x1b vom Telegramm 0x18 0b 08 18 1B 0A <CRC> <Break> Aber leider scheint das nicht so auf dem EMS-Bus funktionieren. Die Hoffnung war wohl zu blauäugig.. Eventuelle muss man alle Datentypen/Telegramm aufeinmal abfragen.. Da hilft nur ein Log am EMS-Bus wenn der Service-Key angeschlossen wird. @Andreas F. (Gast) könntest Du denn evtl. mal einen Log-Versuche starten wenn Du Zeit und die Möglichkeit hast? Also die beschriebene Version mit dem Kabel habe ich am Anfang auch gehabt und Du benötigst keine selbstgeschriebene Software oder irgendwelche andere Hardware außer das Kabel. Eventuell könnte ich Dir das Kabel zuschicken oder evtl. Eine kleine Testplatine mit Programm dafür erstellen und dir zuschicken. Mit der Hardware könnte etwas dauern. das Kabel könnte ich sofort losschicken. liegt hier bei mir auf dem Tisch. Es würde für den Anfang auch erst mal ein serieller Port auch schon reichen.. man könnte dann zumindest sehen ob der Service-Key beim Start ohne EcoSoft-Programm alle Telegramme abfragt und wie er das macht.. Oder wohnt zufällig jemand mit Hardware zum loggen in Deiner Nähe? Ich bin in der Nähe von Münster. hatte damals auch nur ein Kabel ohne Software genommen: Beitrag "Re: Logamatic 2107 Schnittstelle" Gruß Ingo
IngoF schrieb: > Ich bin in der Nähe von Münster. Leider weit entfernt. Mein Nachbar fährt morgen nach Münster übers WE aber das hilft Dir auch nichts. Momentan habe ich keinen verfügbaren Laptop mit geeigneter Schnittstelle zur Verfügung und die anderen Rechner sind wenig portabel. Ich überlege mal am WE, wie ich vielleicht doch was tun kann. Könnte ich die Heizung transportieren, stünde mir ein ganzer Meßpark zur Verfügung. Aber im Winter wäre meine Frau nicht wirklich begeistert. Mhmmm
IngoF schrieb: > Da hilft nur ein Log am EMS-Bus wenn der Service-Key angeschlossen wird. Komme gerade vom Training, sonst hätte ich schon früher Laut gegeben. Ich habe Service-Key, Logasoft und einen RX-Slave ... werde sobald ich Zeit habe die Key-Telegramme mal mitloggen. //Niffko
So, noch nebenbei eine allgemeinere Frage zum Senden: Mein derzeitiger Ablauf: 1. Ich warte auf "0x8B <brk>" 2.1 Nun sende ich meine Abfrage mit einem abschliessenden <brk> 2.2 Danach ein "leeres" Telegram "0x0B <brk>" als Abschluss. Mein Problem: Teilweise bekomme ich die erwartete Antwort. Teilweise aber auch nur "0x80 0x0B <brk>" Ist das überhaupt das richtige Vorgehen zum Senden?
Fred Granna schrieb: > Ist das überhaupt das richtige Vorgehen zum Senden? Das siehst du doch selbst auf dem Bus. Woher hast du überhaupt diesen Ablauf mit Punkt 2.2 ?
Rudi schrieb: > Das siehst du doch selbst auf dem Bus. Woher hast du überhaupt diesen > Ablauf mit Punkt 2.2 ? Den hab ich mir so zusammengereimt. Ich habs nun ohne das leere "Abschlusstelegram" gemacht. Geht auch, ist also nicht nötig. Ich glaube ich habe noch ein paar Timingprobleme...
So ... habe mal den Key eingestöpselt und mir vom Interface nur schicken lassen, was 8B oder 0B auf den ersten beiden Bytes hat - das Ergebnis findet Ihr im Anhang. Das ist wie gesagt nur der blanke Key, ohne Verbindung zur Ecosoft - hierfür bräuchte ich einen zweiten Laptop ... mal sehen. Viel Spaß bei der Lektüre ... //Niffko
Niffko _ schrieb: > So ... habe mal den Key eingestöpselt und mir vom Interface nur schicken > lassen, was 8B oder 0B auf den ersten beiden Bytes hat - das Ergebnis > findet Ihr im Anhang. Das ist ja schonmal nicht schlecht :) Kannst du da evtl. noch Zeitstempel mit einfügen? > Das ist wie gesagt nur der blanke Key, ohne Verbindung zur Ecosoft - > hierfür bräuchte ich einen zweiten Laptop ... mal sehen. Das ist so schonmal ganz gut. So sieht man das im SK wohl eine eigene Logik inkl. Zwischenspeicher drinhängt.
Fred Granna schrieb: > Kannst du da evtl. noch Zeitstempel mit einfügen? Hatte ich versucht. Das Problem ist, Hterm setzt die Zeitstempel nicht immer am Anfang eines Telegrammes sondern immer spätestens nach 16 Bytes - so zerhackt es dann immer die längeren Telegramme. Man kann die überflüssigen Zeitstempel zwar über 'Suchen & Ersetzen' herausoperieren, es fehlen dann aber immer noch die Zeitstempel die nicht gesetzt wurden. Sollten Dich irgendwelche Zeiten im Speziellen interessieren, sag' Bescheid - ich schaue dann mal nach. //Niffko
Gute morgen, ich habe eine andern PC nur Serial Comm, und habst von Conrad eine USB RS232 converter gekauft. Ich habe mit die Ecosoft und Service Key geprobierd, aber kann keine kommunikation starten. Ich habe die Spannungen gemessen und die sind OK, auch eine Scope gebraucht und kann sehen dass das Signal is nicht gleich wenn sendet bei RS232 port. (und dan keine antwort von ServiceKey...) Wo habst eine gleiche setup ? Ins driver kann ich latency, timeouts, ... parameters andern ... vielen danke
Angehängte Dateien:
Guten Morgen, vielleicht kann ich ja mit ein paar Detailbildern des Servicekey ein wenig aufklären. Viel Spaß weiterhin.
Hallo, Andreas F. schrieb: > vielleicht kann ich ja mit ein paar Detailbildern des Servicekey ein > wenig aufklären. Danke für die Bilder. Eine Frage hätte ich da noch. Sind die beiden Optokoppler auf der Seite Heizung<->Schaltung oder PC<->Schaltung ? Grüße.
Hallo, natürlich habe ich nun alles schön wieder zugeschraubt und alle Aufkleber wieder drauf. ;-( Wahrscheinlich hilft Dir das schon weiter. Auf Bild 1 ist der komplette Key dargestellt. Links oben ist der Mini-USB Stecker als Schnittstelle zum PC. Die kleine Platine links unten steckt über dem Controller M306... Unter der kleinen Platine erkennt man die dicken Leiterbahnen. Dort werden die verschiedenen Adapter(Klinkenstecker) aufgesteckt. Viel Spaß
@Andreas F. Okay danke. Dort wird also nur der USB-Teil galvanisch getrennt und der Rest der Schaltung läuft über die ServiceKey Versorgung (12V). So etwas habe ich mir schon gedacht. @all Falls es jemanden interessiert, Junkers benutzt wohl einen vergleichbaren Bus in ihren Geräten mit dem Namen "HT-Bus". Hier der Link zu den Leidgenossen: Beitrag "Junkers HT-Bus Heatronic 3 Schnittstelle" Grüße.
IngoF schrieb: > Hier mal meine aktuelle Sende/Empfangsschaltung....... Der R6 hat da nichts zu suchen. Der hat sich irgendwann eingeschlichen...
Hallo zusammen! Hab mir jetzt mal den Thread so durchgelesen. Ich habe eine Junkers ZSB 14 Therme im Keller mit der Heatronic 3 und würde auch gerne Daten mitloggen und eventuell die Therme steuern. Funktioniert die Schaltung damit oder ist es nur eine Vermutung? Was würde ich alles dazu brauchen oder "bietet" jemand eine fertige an? Bin zwar Elektriker aber mit Platinen/Elektronik hab ich so keine Erfahrung. Liebe Grüße, Christian.
Also ich habe zumindest geplant so eine Platine als "Sammelbestellung" zu machen. Allerdings ist meine Hardware noch in der Entwicklung. Evtl. würde die auch mit der Heatronic laufen. Das einzige was die Platine macht ist die Telegramme in ein PC-Verständliches Format zu bringen (0xAA 0x55 am Anfang und Ende oder eben nach 3964R) Meine PC-Software würde nur funktionieren wenn auch das selbe "Protokoll" darauf läuft und die einzelnen Datenbytes die selbe Bedeutung haben. Eventuelle müsste man dann noch die PC-Software selber entwickeln. Aber erst mal abwarten wie die Telegramm/Daten denn dort eigentlich ausshen... Allerdings habe ich im Moment nicht gaanz so viel zeit an der Hard/Software zu arbeiten. Gruß Ingo
Angehängte Dateien:
-
RX_TX_EMS.png
4,8 KB
Bin ab sofort auch unter den 'Sendenden'. Schaltung siehe Anhang. Basiert, wie weiter oben schon geschrieben, auf einem Soft-UART. Daher auch kein externer Inverter für die Ansteuerung des TX-Transistors, wird per SW erledigt. Habe festgestellt, dass es nicht nötig ist, zwischen dem Senden der Bytes, auf das Echo des Masters zu warten. Man kann die Zeichen einfach hintereinander abfeuern. Könnte das bitte nochmal jemand testen und bestätigen? @IngoF oder Rudi Wenn ihr etwas Zeit übrig habt, könntet ihr euch das ja auch mal mit dem Oszi anschauen. //Niffko
Hallo, Niffko _ schrieb: > Habe festgestellt, dass es nicht nötig ist, zwischen dem Senden der > Bytes, auf das Echo des Masters zu warten. Man kann die Zeichen einfach > hintereinander abfeuern. Könnte das bitte nochmal jemand testen und > bestätigen? Wenn es funktioniert ist es doch okay. Bei der Byteweisen TX/RX-Methode werden Buskollisionen schneller erkannt und der Transfer kann direkt abgebrochen werden. Das Vorgehen halte ich für die bessere Wahl, da wir keine weiteren Informationen zu diesem Bus haben (Verhalten bei Buskollision, Timing etc.) und die Busbelegung bei Fehlern minimiert wird. Grüße.
@Niffko Wenn du Anfragen sendest: Bekommst du immer sofort eine Antwort zurück?
Hallo, hier noch bei paar Oszi.-Bilder vom Bus: Beitrag "Re: Logamatic 2107 Schnittstelle" Beitrag "Re: Junkers HT-Bus Heatronic 3 Schnittstelle" Beitrag "Re: Junkers HT-Bus Heatronic 3 Schnittstelle" Bis auf den Master senden die Slaves immer nur ein Byte und warten auf das Echo. Grüße.
@Niffko Das ist der Vorteil eines Soft-Uart. Du kannst dadurch den invertierenden Komperator/OP einsparen. Beim internen UART würde Die Schaltung ja nicht so funktionieren... Was würdest Du denn gerne am Oszillopgramm überprüft wissen? Also das Echo kommt eigentlich immer sofort am Anschluss an jedes gesendete Byte. Wenn man das nicht überprüfen will ist das ja auch OK. Allerdings hat man dann keine Ahnung ob das Telegramm verstanden wurde und muss dann eben auf die entsprechende Reaktion warten. Eine Garantie dass es verstanden wurde gibt es ja sowieso nicht. @all Hat schon mal jemand irgendwann gesehen was am Bus passiert wenn man ein Telgramm mit der falschen CRC auf den Bus schiebt? Hatte ja gemerkt dass nach dem Break ein 0xFE gesendet wird wenn man selber mit einem Low-Pegel unter 10 Volt sendet. Vermute aber schon dass das nicht eine gewollte Reaktion ist und keine Fehlermeldung vom Busmaster. Meine Sendehardware ist soweit auch schon betriebsbereit und funktioniert soweit ganz gut. Die Software sollte auch schon zu fertig sein, aber habe im Moment nicht Zeit daran weiter zu basteln... Gruß Ingo
Niffko _ schrieb: > Habe festgestellt, dass es nicht nötig ist, zwischen dem Senden der > Bytes, auf das Echo des Masters zu warten. Man kann die Zeichen einfach > hintereinander abfeuern. Könnte das bitte nochmal jemand testen und > bestätigen? Achso.. hatte das wohl falsch verstanden... Der Busmaster bekommt ja nicht mit ob Du die Bytes einliest/prüfst oder einfach das Echo ignorierst. Also wird das warten nicht nötig sein... Oder wolltest Du wissen WANN das Echo kommt? Das Echo kommt immer sofort ohne große Wartezeiten oder Pausen.
Fred Granna schrieb: > Wenn du Anfragen sendest: Bekommst du immer sofort eine Antwort zurück? Kann ich (noch) nicht sagen, ich habe keine Anfragen gesendet, sondern eher Mitteilungen. Rudi schrieb: > hier noch bei paar Oszi.-Bilder vom Bus: > > ... > > Bis auf den Master senden die Slaves immer nur ein Byte und warten auf > das Echo. Korrigiere mich bitte - aber auf den Beispielbildern mit Echos sind samt sonders nur Polling Antworten ('Ja, ich lebe noch!') zu sehen. Ein Daten-Telegramm eines Busteilnehmers ist nicht dabei, daher reicht mir das noch nicht als 'Beweis' ;-) //Niffko
IngoF schrieb: > Das ist der Vorteil eines Soft-Uart. Du kannst dadurch den > invertierenden Komperator/OP einsparen. Beim internen UART würde Die > Schaltung ja nicht so funktionieren... jep ... Recht hast Du. Ist zwar etwas mehr Programmieraufwand, aber wenn ich dadurch Hardware einspare, ist das o.k. IngoF schrieb: > Der Busmaster bekommt ja nicht mit ob Du die Bytes einliest/prüfst ... Das nicht, aber er würde mit seinem Echo mein nächstes Byte plattbügeln, wenn er stur nach jedem empfangenen Zeichen ein Reply sendet. IngoF schrieb: > Oder wolltest Du wissen WANN das Echo kommt? Ich würde gerne wissen, wie das Oszillogramm aussieht, wenn man ein Daten-Telegramm 'am Stück' auf den Bus gibt. Theoretisch müsste dann darauf ja auch ein Echo 'am Stück' folgen. Das Echo kommt immer sofort > ohne große Wartezeiten oder Pausen. Eine kleine Pause gibt es lt. den Oszi-Bildern aber schon. Die würde auch ausreichen um zu erkennen ob noch ein Zeichen folgt, da auf das Stop-Bit(H) des gesendeten Bytes sofort das Start-Bit(L) das nächsten Bytes kommen würde. //Niffko
Hallo zusammen ich bin erstmalig hier im Forum. Zuerst zu meiner Person: ich besitze eine Anlage mit folgenden Eigenschaften: GB 142 (Bj 2004) UBA3/MC10: Version 2.05 BC10: Version 2.00 RC30: Version 2.05 Nach Kauf im Jahr 2004 und grober Analyse des EMS-Bus-Protokolls hatte ich damals eine ansatzweise Betriebsdatenaufzeichnung mit 16bit uC aufgebaut. Allerdings konnte ich die Prüfsumme nicht herausfinden. Auch der Polling-Mechanismus war mir im Detail unklar geblieben (besitze kein Oszi). Deshalb hier an alle vielen Dank für die Arbeit, insbes. an Rudi (24.10.2010) und auch IngoF für die CRC-Berechnung. Mit dem Wissen ist es jetzt viel einfacher, Logging-Informationen zuverlässig auszuwerten. Allerdings sind meine Kenntnisse von damals (2004) schon fast wieder vergessen. Zur Frage der Schaltprogramme von IngoF (06.01.2011): IngoF schrieb: > Hatte nur meine Einstellungen hier genannt falls hier irgendjemand eine > Idee mit der Zuordnung der Daten zu den Schaltzeiten hat.. Nach Veränderung eines Schaltprogramms am RC30 sendet der RC30 offenbar einmalig vier Telegramme mit dem kompletten Inhalt des jeweils geänderten Schaltprogramms. Die entsprechenden Telegramme sind (bei meiner RC30): 10 00 3f für Heizkreis 1 10 00 38 für Warmwasser 10 00 39 für Zirkulation. Beispiel für ein geändertes Schaltprogramm am Heizkreis 1 (Log incl. CRC) Msg: 10 00 3f 00 01 1e 00 82 21 1f 20 82 41 1f 40 82 61 1f 60 82 81 1f 80 82 a1 20 a0 82 c1 20 c0 11 Msg: 10 00 3f 1b 82 e7 90 e7 90 e7 90 e7 90 e7 90 e7 90 e7 90 e7 90 e7 90 e7 90 e7 90 e7 90 e7 90 b0 Msg: 10 00 3f 36 e7 90 e7 90 e7 90 e7 90 e7 90 e7 90 e7 90 e7 90 e7 90 e7 90 e7 90 e7 90 e7 90 e7 23 Msg: 10 00 3f 51 90 e7 90 00 00 00 11 08 0a 0a 09 0a 01 01 00 01 01 00 97 Die vier Telegramme enthalten den Speicherbereich des Schaltprogramms (99 Bytes Nutzdaten): Byte 4: Startadresse des Speicherbereich-Blockes Byte 5-Ende (vor CRC): Nutzdaten (3 x 27 Bytes und 1 x 18 Bytes). Die Nutzdaten enthalten nach meiner Einschätzung: 42 * 2 Bytes mit Schaltzeiten und weitere 15 Bytes (Inhalt unklar). Ein Schaltpunkt enthält die beiden Bytes: 0xXY 0xZZ mit X = Tag (0=Mo, 2=Di, C=So, E=Schaltpunkt undefiniert), Y = Schalten (0=Aus, 1=Ein, 7=Schaltpunkt undefiniert), ZZ = Zeitpunkt (00=00:00, ... 8f=23:50, 90=undefiniert). Beispiel: 01 1e : Montag, Ein, 5:00 Vielleicht findet jemand noch die Bedeutung der restlichen Bytes heraus ?
Niffko _ schrieb: > daher reicht mir > das noch nicht als 'Beweis' ;-) Na wenn Du Beweise brauchst.... ;o) Beitrag "Re: Logamatic 2107 Schnittstelle" Gut, man kann es nicht wirklich 100% erkennen. Aber als ich noch näher herangezoomt habe konnte man gut sehen dass nach jedem gesendeten Byte ein EchoByte vom Master kommt. Beide Bilder sind aus der selben Messung. Niffko _ schrieb: > Das nicht, aber er würde mit seinem Echo mein nächstes Byte plattbügeln, > wenn er stur nach jedem empfangenen Zeichen ein Reply sendet. habs mir doch fast gedacht dass Du es nicht so vertanden hast wie ich es gemeint hatte. Die RC30 wartet immer auf ein Echo bevor das nächste Byte kommt. Kann sein dass der Master erkennt wenn jemand ein ganzes Paket ohne Pause sendet und dann keine Echo sendet. Allerdings würde ich empfehlen es genau so zu machen wie die RC30. Also nach jedem Byte ein Byte Pause machen oder das Echo einlesen und zu vergleichen. Der einzige der ohne die 1-Byte-Pause zwischen den Sendebytes sendet ist der Busmaster. Habe allerdings auch mal ein Telegramm am OSzillioskop gesehen das in mehreren Bröckchen gesendet wurde. Kann das allerdings nicht mehr nachfollziehen. Wäre möglich dass auf dem EMS-Bus nur gesendet werden darf wenn ein Echo gesendet wurde. Kann ja sein dass der Busmaster kurz beschäftigt ist und dadurch dem Sender eine Pause aufzwingen kann. Vielleicht funktioniert ja auch das Dein "drauflospusten" und macht erst Probleme wenn irgendwelche Komponenten z.B. mit neuerer Firmware in der Heizung ausgetauscht werden. MartinQ schrieb: > ... insbes. an Rudi ... und auch IngoF für die CRC-Berechnung. ... Danke, sieht man nicht wirklich wieviel Zeit ich mit der Tabellenkalkulation verbracht habe um das erste Ergebnis zu bekommen. Aber der Entscheidende Hinweis kamm dann von Rudi, dass bei gesetzten Bit7 der CRC nochmal mit einem Wert (0x12?) geXORed wurde. Hätte ich vermutlich nie herausgefunden! Hab schon echt verzweifelt ;o) Wusste nur dass es mit den getesteten Telegrammen ohne >0x80 funktioniert hatte. Aber gut dass es das Internet und Mikrocontroller.net gibt.... MartinQ schrieb: > Vielleicht findet jemand noch die Bedeutung der restlichen Bytes heraus ? Das ist nur eine Frage der Zeit. Das ist ja einer der Hauptgründe warum ich an den EMS-Bus wollte.... Denke aber dass da noch jemand schneller sein wird als ich. Gruß Ingo
00 11 08 0a 0a 09 0a 01 01 00 01 01 0 Stunden Party Funktion 17.08.2010 Urlaubstart Tag Urlaubstart Monat Urlaubstart Jahr 10.09.2010 Urlaubende Tag Urlaubende Monat Urlaubende Jahr 01.01.2010 Feiertagstart Tag Feiertagstart Monat Feiertagstart Jahr 01.01.2000 Feiertagende Tag Feiertagende Monat Feiertagende Jahr
Hallo, Niffko _ schrieb: > Korrigiere mich bitte - aber auf den Beispielbildern mit Echos sind samt > sonders nur Polling Antworten ('Ja, ich lebe noch!') zu sehen. Ein > Daten-Telegramm eines Busteilnehmers ist nicht dabei, daher reicht mir > das noch nicht als 'Beweis' ;-) Könntest du einfach mal senden und dir die empfangenen Daten anzeigen lassen ? Wenn du deine gesendeten Daten nicht siehst, dann funktioniert es nicht, bzw. erkennt der Busmaster deine Daten nicht. Grüße.
IngoF schrieb: > 01.01.2010 > Feiertagstart Tag > Feiertagstart Monat > Feiertagstart Jahr > > 01.01.2000 > Feiertagende Tag > Feiertagende Monat > Feiertagende Jahr musste eigentlich heissen: 10.01.2001 00.01.2001 Keine Ahnung warum dort 00 als Tag steht...
IngoF schrieb: > Keine Ahnung warum dort 00 als Tag steht... Da gibt es mehrere Variationen ;-). Je nachdem wann der erste des Monats und der erste Monat anfängt, mit der Zeit das gleiche, steht da 0 oder 1. Bei den Wochentagen gibt es glaube ich auch nette Variationen, einmal fängt er Sonntags an, einmal Montags ....
Ingo F. schrieb: > habs mir doch fast gedacht dass Du es nicht so vertanden hast wie ich es > gemeint hatte. ... Kann sein dass der Master erkennt wenn jemand ein > ganzes Paket ohne Pause sendet und dann keine Echo sendet. ... habe dich schon verstanden und der letzte Satz ist genau der Punkt. Es ist ja offensichtlich so, dass der Master nicht dogmatisch darauf besteht, nach jedem Zeichen ein Echo zu senden. Sonst hätte ich ja mein gesendetes Telegramm nicht auf dem Bus sehen können. Ingo F. schrieb: > Allerdings würde ich empfehlen es genau so zu machen wie die RC30. Naja ... aber ein gutes Pferd springt immer nur so hoch wie es muss ;o) Ingo F. schrieb: > Vielleicht funktioniert ja auch das Dein "drauflospusten" ... uhhh ... drauflospusten klingt irgendwie so negativ! **schmoll** Rudi schrieb: >Könntest du einfach mal senden und dir die empfangenen Daten anzeigen >lassen ? Hatte ich natürlich gemacht. Wie hätte ich auch sonst feststellen sollen, dass keine Pausen notwendig sind. Ursprünglich wollte ich austesten wie weit man es mit den Sendepausen treiben kann und habe die Zeit zwischen Polling-Antwort und Break immer weiter ausgedehnt. Als dann bei 255 Bitlängen immer noch niemand gemeckert hat und ich ohne Weiteres nicht mehr erhöhen konnte, war der nächste logische Schritt, es auch mal ganz ohne Pause zu versuchen. Meine Sendungen wurden immer ordnungsgemäß vom Master auf den Bus geschoben. //Niffko
Niffko _ schrieb: > war der nächste logische Schritt, es > auch mal ganz ohne Pause zu versuchen. Meine Sendungen wurden immer > ordnungsgemäß vom Master auf den Bus geschoben. Na dann war dass wohl ein Missverständnis. Du hast vermutlich Pausen eingelegt zwischen dem Echo vom Busmaster und dem nächten Byte... Man muss garkeine Pausen machen. Also Byte senden. Master sendet ohne Pause das Echo. Sofort wenn das Echo empfangen wurde kann das nächste Byte gesendet werden. Niffko _ schrieb: > Naja ... aber ein gutes Pferd springt immer nur so hoch wie es muss ;o) Ist nur dumm wenn das Pferd nur gerade so hoch springen kann um gerade so über die Hürden zu kommen. Wenn jetzt aus irgendwelchen Gründen die Hürden 1mm höher werden hat Dein Pfer aber ein Problem und bleibt hängen. Oder Dein Pferdchen hat mal einen schlechten Tag oder ist mit dem falschen Fuß aufgestanden.... Wer weiss ;o) Niffko _ schrieb: > uhhh ... drauflospusten klingt irgendwie so negativ! **schmoll** Hatte es so verstanden dass Du nach dem ersten Byte sofort ohne auf das Echo zu warten das nächste hinterher schickst. Denke der Busmaster dürfte aber mehr Puste haben, und Dein nächstes Byte mit seinem Echo wegpusten.... Gruß Ingo
Ganz vergessen.. Mit dem Alter schrumpft man ja auch ein wenig. Spätestens dann hat Dein "gerademalsodrüberhüpdpferdchen" Probleme :D
IngoF schrieb: > Na dann war dass wohl ein Missverständnis. > Du hast vermutlich Pausen eingelegt zwischen dem Echo vom Busmaster und > dem nächten Byte... Oh mann, hier hat das geschriebene Wort wohl mal wieder so richtig seine Tücken. Ich versuch's jetzt nochmal: mit Pause Master sendet : 8X <brk> Ich sende : 0X P XX P XX P XX P XX P XX P <BRK> Ich empfange : 0X XX XX XX XX XX <BRK> ohne Pause Master sendet : 8X <brk> Ich sende : 0X XX XX XX XX XX <BRK> kontinuierlicher Stream, auf Stop-Bit folgt Start-Bit, keine Pausen Ich empfange : 0X XX XX XX XX XX <BRK> > Niffko _ schrieb: >> Naja ... aber ein gutes Pferd springt immer nur so hoch wie es muss ;o) > > Ist nur dumm wenn das Pferd nur gerade so hoch springen kann um gerade > so über die Hürden zu kommen. Ich schrieb: so hoch wie es muss, nicht wie es kann. > Wenn jetzt aus irgendwelchen Gründen die Hürden 1mm höher werden hat > Dein Pfer aber ein Problem und bleibt hängen. Ein gutes Pferd sieht das und springt dann ebend höher. > Oder Dein Pferdchen hat mal einen schlechten Tag oder ist mit dem > falschen Fuß aufgestanden... Wenn es schlechte Tage hat, ist es kein gutes Pferd. So ... jetzt ist aber gut ;o) IngoF schrieb: > Hatte es so verstanden dass Du nach dem ersten Byte sofort ohne auf das > Echo zu warten das nächste hinterher schickst. ja ... richtig ... geht doch. IngoF schrieb: > Denke der Busmasterdürfte aber mehr Puste haben, und Dein nächstes > Byte mit seinem Echo wegpusten.... Genau das ist der Punkt ... er pustet ebend nicht ... obwohl er könnte. //Niffko
Hallo, Niffko _ schrieb: > IngoF schrieb: >> Denke der Busmasterdürfte aber mehr Puste haben, und Dein nächstes >> Byte mit seinem Echo wegpusten.... > Genau das ist der Punkt ... er pustet ebend nicht ... obwohl er könnte. Du kannst aber nicht wissen wann der Master senden will und das ist das Problem. Wenn der Bus auf Low gehalten wird darf nicht gleichzeitig gesendet werden. In den Scope Bildern von mir siehst du auch wie der Master gleichzeitig sendet, okay mein Sendepegel war etwas zu groß, aber das sollte erst einmal egal sein. Grüße.
Nur mal eine Vermutung von mir: An anderer Stelle hat mal einer erwähnt, das der Empfänger des Masters auf die durch den Transistor und den 220 Ohm Widerstand erzeugten Stromschwankungen reagiert, anstatt auf die eher geringen Spannungsschwankungen. Der Strom ist bei 15V damit beim Senden um 68mA höher, bei 10V (Low) um 45mA höher als der Ruhestrom. Warum soll der Master also nicht auch unabhängig von seiner eigenen Sendeaktivität gleichzeitig in der Lage sein zu empfangen? Es reicht doch, wenn die Ansprechschwelle des Empfängers z.B. bei 30mA liegen würde! Damit könnte ich mir vorstellen das der Master brav nach jedem empfangenen Byte sofort das Spannungsecho sendet und parallel dazu auf seiner Stromschnittstelle das nächste Byte empfängt. Der Sendeschaltung ist es auch schitegal ob sie mit statisch 15V oder mit modulierten 10/15V beaufschlagt wird. BTW: Nachdem ich jetzt auch mal mitrede zu meiner Person: Buderus GB162 Windhager Logwin UVR1611 Den GB162 steuere ich über Leistungsmodulation (10V mit Original EM10, hallo Niffko :-) ) Bislang hab ich nur mitgelesen (und werd es wohl auch im wesentlichen auch in Zukunft tun) da ich momentan mich eher darauf konzentiere zu versuchen das LON-Protokoll zu entschlüsseln weil ich das was ihr hier macht mit dem Logwin machen möchte.... Am Ende sollen sowohl der Logwin als auch der GB162 mit entsprechenden Interfaces direkt via OpenCAN von der UVR1611 gesteuert/ausgelesen werden.
rkoch schrieb: > Warum soll der Master also nicht auch unabhängig von seiner eigenen > Sendeaktivität gleichzeitig in der Lage sein zu empfangen? Es reicht > doch, wenn die Ansprechschwelle des Empfängers z.B. bei 30mA liegen > würde! Das wäre vielleicht die Erklärung warum es bei Niffko so funktioniert.
IngoF schrieb: >> Warum soll der Master also nicht auch unabhängig von seiner eigenen >> Sendeaktivität gleichzeitig in der Lage sein zu empfangen? Es reicht >> doch, wenn die Ansprechschwelle des Empfängers z.B. bei 30mA liegen >> würde! > > Das wäre vielleicht die Erklärung warum es bei Niffko so funktioniert. Dann bräuchte der Master aber 2 Empfänger bzw. eine Umschaltung der beiden bei TX und RX, denn das LOW bekommt er nicht durch Luft und Liebe auf den Bus. Zusätzlich ist der Bus nicht Taktsynchron, ergo funktioniert das so nicht. Grüße.
IngoF schrieb: > Hat schon mal jemand irgendwann gesehen was am Bus passiert wenn man ein > Telgramm mit der falschen CRC auf den Bus schiebt? Was Telegramme angeht, die für den Busmaster(08) bestimmt sind, kann ich hierzu Folgendes sagen. Grundsätzlich werden auch Telegramme mit falscher CRC auf den Bus 'ge-echot'. Beim Senden mit Unterbrechung ist das natürlich logisch und nicht zu verhindern. Aber auch wenn mann das Telegramm im Paket absetzt und der Busmaster vor dem Wiederholen die Möglichkeit zur Prüfung hätte, wird das fehlerhafte Telegramm auf den Bus gegeben. Ein fehlerhaftes Telegramm wird dann allerdings vom Master mit 0x04 <brk> quittiert, wogegen ein korrektes Telegramm ein 0x01 <brk> bekommt. Somit wäre das auch eine gute Möglichkeit eine abgesetzte Sendung zu verifizieren. //Niffko
> Dann bräuchte der Master aber 2 Empfänger bzw. eine Umschaltung der > beiden bei TX und RX, denn das LOW bekommt er nicht durch Luft und Liebe > auf den Bus. Zusätzlich ist der Bus nicht Taktsynchron, ergo > funktioniert das so nicht. Wenn ich mich nicht irre wissen wir über die Sendeschaltung des Masters recht wenig. Da es möglich ist auf einer Busleitung eine spannungsgesteuerte und eine stromgesteuerte Übertragung mit annähernd 100%iger Kanaltrennung zu fahren könnte ich mir sehr wohl vorstellen das das funktioniert. So lange unser System nicht Multi-Master-Fähig ist (ist es das ?) bräuchte der Master genausowenig wie die Clients 2 Kanäle. Bei ihm wäre nur die Sende/Empfangsschaltung genau konplementär zu der der Clients... Da man der Sendeschaltung des Masters offenbar einiges an Strom zumuten kann würde ein zweiter Master mit Spannungssignalisierung IMHO nicht funktionieren. Insofern wäre Multi-Master IMHO nur möglich, wenn man den Master in zwei Funktionalitäten trennt: Bus-Master und Device Master, d.h. der Bus Master ist der einzige am Bus mit Spannungssender, Device Master senden und empfangen (solange sie nicht zugleich Bus-Master sind) wie Clients, aber machen das Polling für ihre Clients. Ob es so was wie Multi-Master gibt kann ich aus den bisherigen Beiträgen auf die Schnelle nicht herauslesen. I.d.R. kommen hier wohl nur entweder Logamatic oder BC10 als Master vor.... Falls es doch mehrere Master am Bus gibt müssen diese aber eigentlich nur im Moment des Einschaltens sich einig werden wer den Bus-Master macht - im simpelsten Fall einfach indem derjenige der beim Einschalten 0V auf dem Bus sieht seine Treiber aktiviert. Der Verlierer in dieser Selektion schaltet dann einfach sein RX/TX auf das Client-Interface. Ich weiß zwar absolut nicht ob das so läuft, aber vorstellbar wäre es - gibt es schließlich in anderen Systemen nicht viel anders. Die Master-Sendeschaltung stelle ich mir relativ primitiv vor: 2 Spannungsquellen (15V/10V), die 10V einfach über eine Diode (oder einen Transistor) auf den Bus geschaltet, die 15V immer über Transistor. Eventuell auch noch einfacher: 15V und Spannungsdrop von ~5V durch eine 5V-Leistungs-Z-Diode die mit einem Transistor überbrückt wird. Als Stromempfänger dann einfach ein Widerstand (ca. 6 Ohm), deshalb der Spannungsabfall von ca. 0,5 V bei ~70mA, der Ruhestromwert über Tiefpass auf Comparator, der Impulsstromwert direkt. Vieleicht fabiluiere ich hier nur ins Blaue hinein, aber technisch vorstellbar wäre so was.
Kurze Zwischenfrage: Kann mir einer von euch ein wenig C-Code zur Verfügung stellen? Bekomme das mit dem Software-UART leider nicht richtig hin :-(
Fred Granna schrieb: > Bekomme das mit dem Software-UART leider nicht > richtig hin :-( Denke da kann Dir wohl nur Niffko weiterhelfen. Hier noch mal der Link mit dem Soft-UART-Link von Niffko: Beitrag "Re: Logamatic 2107 Schnittstelle" Sonst verwenden hier ja wohl alle die hier gepostet haben einen Hardware UART. Was hast Du denn für ein Problem mit dem Soft-UART? Der i2c-UART ist Geschichte?? Niffko _ schrieb: > Grundsätzlich werden auch Telegramme mit > falscher CRC auf den Bus 'ge-echot'. Das hatte ich mir auch schon fast gedacht. Der Master kann die Prüfsumme ja erst vergleichen wenn das Telegramm zu ende ist und das letzte Break gesendet wurde. Niffko _ schrieb: > Ein fehlerhaftes Telegramm wird dann allerdings vom Master > mit 0x04 <brk> quittiert, wogegen ein korrektes Telegramm ein 0x01 <brk> > bekommt. Habe die Quittierung bisher noch nie gesehen. Kann aber sein dass die im Polling untergegangen ist. Kommt das sofort nach dem Telegramm, oder erst nach dem 0x0b <break> wenn Die "Kontrolle" zurück gegeben wird? Gruß Ingo
IngoF schrieb: > Denke da kann Dir wohl nur Niffko weiterhelfen. Hier noch mal der Link > ... Hatte Niffko ne PM geschickt aber keine Antwort bekommen... > Sonst verwenden hier ja wohl alle die hier gepostet haben einen Hardware > UART. Nehme ich ungern, der Atmega328 von meinen Boards ja nur eine. > Was hast Du denn für ein Problem mit dem Soft-UART? Der i2c-UART ist > Geschichte?? Mit dem i2c-Uart hab ich leider Timingprobleme. Die Break-Erkennung ist zu langsam da ich den Chip nur über Polling ansprechen kann.
@Fred Granna Hast Du Dir die App-Note AVR304 (http://atmel.com/dyn/resources/prod_documents/doc0941.pdf bzw. http://atmel.com/dyn/resources/prod_documents/avr304.zip) schon mal angeschaut? Ist doch eigentlich ganz gut dokumentiert und auch nicht wirklich kompliziert. Die einzige Änderung wäre doch anstatt des externen Interrupts den Comparator-IRQ zum Starten des Empfangs zu verwenden und dann natürlich anstatt des IO-Ports den Ausgang des Comparators zum Empfang zu verwenden.... und natürlich ggf. den IAR-Code an z.B. gcc (WinAVR) anzupassen.
Fred Granna schrieb: > Hatte Niffko ne PM geschickt aber keine Antwort bekommen... öhmm, sorry ... war keine böse Absicht. Das Motherboard von meinem Dell ist mal wieder im Eimer und auf dem Laptop habe ich keinen Email-Krams drauf. Meinen AVR-Code möchte ich aber momentan keinem zumuten, der ist noch zu 'Baustelle'. Formuliere doch mal die Probleme die Du hast, dann kriegen wir das schon hin. Vielleicht hilft's ja auch dem Ein oder Anderen mit ähnlichen Problemen. Ich habe z.B. einen Gutteil Zeit investiert um herauszufinden, dass ich die Anzahl der Timertakte für eine Bitlänge von 417 auf 400 korrigieren muss (F_CPU 4MHz). Längere Telegramme wurden zum Schluss hin immer falsch eingelesen, da die Abtastung zeitlich aus dem Ruder lief. Wenn Du den Soft-UART von P.D. in alles Einzelheiten verstanden hast, solltest Du das eigentlich hinbekommen. Also ... lass mal hören, wo die Säge klemmt. //Niffko
Niffko _ schrieb: > Ich habe z.B. einen Gutteil Zeit investiert um herauszufinden, dass ich > die Anzahl der Timertakte für eine Bitlänge von 417 auf 400 korrigieren > muss (F_CPU 4MHz). Längere Telegramme wurden zum Schluss hin immer > falsch eingelesen, da die Abtastung zeitlich aus dem Ruder lief. 417 wäre aber definitiv richtig... Kann es sein, das Du den Timer immer wieder neu aufsetzt anstatt ihn einfach im PWM Mode mit IRQ bei Overrun laufen zu lassen? Dann musst Du natürlich die Zeit die der AVR zum Setzen des Zählers braucht abziehen... Trotzdem gibt das u.U. immer noch genug Jitter um aus dem Ruder zu laufen, je nachdem ob Du noch andere IRQs aktiv hast.
rkoch schrieb: > 417 wäre aber definitiv richtig... tja ... wem sagst Du das. Vielleicht geht mein Quarz ja 'etwas' nach. :D rkoch schrieb: > Kann es sein, das Du den Timer immer wieder neu aufsetzt anstatt > ihn einfach im PWM Mode mit IRQ bei Overrun laufen zu lassen? Negativ. Timer1 wird bei Programmstart einmal auf volle Bitzeit initialisiert und läuft danach permanent im CTC-Mode. Der TX-Algo läuft in der OutputCompareA ISR. RX wird über InputCapture gestartet (Startbit) und OutputCompareB einmalig so gesetzt, dass die Abtastung in der OutputCompareB ISR eine halbe Bitzeit später beginnt. Von daher dürften eigentlich keine Abweichungen entstehen. //Niffko
IngoF schrieb: > Habe die Quittierung bisher noch nie gesehen. Kann aber sein dass die im > Polling untergegangen ist. Kommt das sofort nach dem Telegramm, oder > erst nach dem 0x0b <break> wenn Die "Kontrolle" zurück gegeben wird? Hallo Ingo, nachfolgend ein Paar Snippets zum Thema Quittierung. Quittierung 'standard':
1 | 91 00 |
2 | 11 08 1E 00 00 F9 9B 00 |
3 | 01 00 |
4 | 11 00 |
Quittierung 'mittendrin':
1 | 90 00 |
2 | 10 88 11 24 18 29 00 |
3 | 08 10 11 24 36 41 00 E3 8B 01 11 11 2C 00 00 00 04 00 |
4 | 10 88 11 30 0C 15 00 |
5 | 08 10 11 30 36 41 00 E3 8B 01 11 11 2C 00 00 00 4A 00 |
6 | 10 08 35 00 01 01 00 00 |
7 | 01 00 |
8 | 10 88 1C 00 17 5A 00 |
9 | 08 10 1C 00 00 00 00 00 00 00 00 00 00 00 00 62 00 |
10 | 10 00 |
Folgendes ist mir erst kürzlich aufgefallen. Es widerlegt meine These, dass nur Telegramme an den Master(08) quittiert werden und wirft die Frage auf, wer überhaupt quittiert - der Master oder der jeweilige Empfänger!? Ich wäre ja fast für Letzteres.
1 | 90 00 |
2 | 10 11 9D 00 64 B3 00 |
3 | 01 00 |
4 | 10 91 02 00 03 FE 00 |
5 | 11 10 02 00 47 01 01 30 00 |
6 | 10 00 02 00 56 01 06 01 00 |
7 | 10 00 |
//Niffko
Niffko _ schrieb: > der Master oder der jeweilige > Empfänger!? Ich wäre ja fast für Letzteres. Na das wird sich ganz einfach feststellen lassen... Allerdings habe ich noch einen Bug in meiner Senderoutine. Irgendwie gibt es noch Probleme mit dem Vergleich der gesendeten Bytes. Wenn die Quittierung von der MC30 kommt wenn ich ein Telegramm an sie sende sollte man erst den Sendepegel der RC30 sehen und anschließend das Echo vom Busmaster. Wenn der Busmaster die Telegramme quittiert fehlt der. Wenn irgendjemand die Telegramme quittiert die man von anderen Busteilnehmern bekommt, dann kann es nur der Master sein. Bin auch für die Vermutung dass der Empfänger quittiert. Aber bisher natürlich nur eine Vermutung. Mir ist gerade aufgefallen dass nur Telegramme bestätigt werden in denen das Bit7 nicht gesetzt ist. Also nur Telegramme auf die sonst keine Antwort vom Empfänger kommt. Vermutlich auch ein Zeichen dafür dass der Empfänger bestätigt.... Gruß Ingo
IngoF schrieb: > Na das wird sich ganz einfach feststellen lassen... ... sagt jemand, der ein DSO sein Eigen nennt - wer hat der kann ^^ //Niffko
Hallo, habe noch mal meine alten LOG-Files durchsucht. Es sieht so aus als ob Das Telegramm 10 00 06 ..... immer bestätigt wird. Telegramme an die 21 wurden nicht bestätigt. An die 08 allerdings schon.. Also hat das nicht nur was mit dem Polling zu tun... Allerdings war das beim herausfinden der Adressen am EMS-Bus und die 0x21 bin ich gewesen (Hatte nutr Polling beantwortet) Einmal kam die 01 ohne dass das Polling an die 10 rausgegangen ist und dannach Antwortet die 10 (MC30) Oder ist das ein Check ob die die RC30 noch da ist? Macht ja auch wenig Sinn.. es gibt ja das Polling. Die "Quittierung" kommt sogar mal ganz spontan ohne irgendwelche Telegramme. Vielleicht wird es zusätzlich jede Minute die keine Telegramme versendet wurden auch auf den Bus gegeben. Allerdings hatte ich damals noch einen großen Buffer und die Zeiten ändern sich selten. Kann also im Moment nicht sagen wie lange die Pause sein kann.... Die Qutittierung 04 habe ich allerdings garnicht gefunden. Hier mal ein paar Ausschnitte die ich Beispielhaft aus meinen Log-File geschnibbelt habe:
Niffko _ schrieb: > ... sagt jemand, der ein DSO sein Eigen nennt - wer hat der kann ^^ Genau das hatte ich auch damit gemeint.. Allerdings ärgert mich noch meine Senderoutine. Der Vergleich will nicht immer klappen... Also wenn ich soweit bin werde ich mal danach gezielt suchen... Bis dahin kann ich nur dannach in meinen Log-Files suchen und wild herumspekulieren ;o) Gruß Ingo
IngoF schrieb: > Telegramme an die 21 wurden nicht bestätigt ... und die > 0x21 bin ich gewesen (Hatte nutr Polling beantwortet) ok ... das spricht dafür, dass der Empfänger quittiert. Denn als solcher wärst Du offensichtlich dafür verantwortlich gewesen, hast es aber nicht getan. IngoF schrieb: > Die Qutittierung 04 habe ich allerdings garnicht gefunden. ... hierfür wirst Du ein Telegramm mit einer falschen CRC schicken müssen. Wie es aussieht, ist der Bus, was Fehler angeht, ziemlich robust. //Niffko
Niffko _ schrieb: > ok ... das spricht dafür, dass der Empfänger quittiert. Mich stört nur noch das ab und zu die 01 Grundlos mitten im Polling auftaucht.. Aber vermute mal das war irgend ein Fehler in meiner Software. Es trat immer vereinzelt auf und danach kam eine Antwort von der 10 (MC30) ohne Polling.. Hätte also eigentlich eine 90 sein müssen... Niffko _ schrieb: > Wie es aussieht, ist der Bus, was Fehler angeht, ziemlich > robust. Also in 137 MByte (60Stunden) kein einziges fehlerhaftes Telegramm ist doch auch schon mal was
Hallo, ich sehe die 0x01 auch ;-). Die Bestätigung wird offensichtlich nur gesendet, wenn "Werte" gesetzt werden: => 10 08 1a 00 38 64 64 00 09 => 01 => 10 08 35 00 11 11 30 => 01 Wenn in der Bedienung ein paar Werte geändert werden, sollte die 0x01 auch zu sehen sein !? Grüße.
Angehängte Dateien:
-
3964R-Terminal.jpg
54 KB
Hallo an alle... im Moment tut sich ja nicht mehr viel in diesem Thread. Aber eigentlich ist ja inzwischen schon fast alles bekannt. Habe schon mal das 3964R-Protokoll "eingebaut". Falls jemand sowas ähnliches vorhat und das noch testen will kann ja mal mein kleines 3964R-Terminal Programm ausprobieren. Zu finden http://modelledit.rc-sim.de unter Downloads. Den Trace kann man nur sehen wenn das Programm über die Batchdatei oder über Console mit java -jar Terminal-3964R aufgerufen wird. der "löschen"-Knopf hat noch keine Funktion. Als Paramter kann man noch den seriellen Port übergeben. Sollte auch unter Linux oder auf dem MAC laufen. Habe es allerdings noch nciht getestet. Einfach "COM1" auf den entsprechenden Namen ändern. Java 1.6 ist Mindestvorraussetztung. Wer das Programm hilfreich findet kann ja eine Kleinigkeit an Unicef spenden. Installation: Entpacken und starten :-) Gruß IngoF
Hallo, erstmal an alle Lob und Anerkennung, ich lese schon längere Zeit mit. Da es aber sehr viel ist, finde ich es gut wenn man eine Zusammenfassung vom heutigen Stand hätte. Ich selbst habe eine Buderus Heizungsanlage aus dem Jahr 2003: GB142-24 RC30 MM10 WM10 da ich den PIC 18F2550 / 18F4550 programmiere bin ich an ein Programm für diesen interessiert. Also die Schnittstelle zum EMS Bus. Ich möchte zuerst nur einmal die Störmeldungen abfragen falls das Gerät ausfällt. Später möchte ich evtl. der RC30 Temperatur-Sollwerte vorgeben. Ich denke das ist nach dem heutigen Stand möglich. IngoF schrieb: > Also ich habe zumindest geplant so eine Platine als "Sammelbestellung" > > zu machen. Allerdings ist meine Hardware noch in der Entwicklung. @IngoF an eine Sammelbestellung bin ich interessiert, soll es ein PIC sein? mich würde auch deine Firmware interessieren (für PIC). Welche Programmiersprache benutze Du? Macht es einen Sinn die Komperatoreingänge zu benutzen? Gruß pic18f
F. F. schrieb: > da ich den PIC 18F2550 Ich habe den 18F258 bisher verwendet und nehme jetzt den 18F2580. Der 18F2550 hat keine eingebaute CAN-Schnittstelle. Mit den Komperatoreingängen habe ich mich nicht beschäftigt. Wenn man diese beutzen möchte kann man den eingebauten EUSART nicht nutzen und müsste auf einen Soft-UART zurückgreifen. Aber irgendwie sind mir persönlich externe Komperatoren lieber. Notfalls kann man die auch austauschen. Vermutlich werde ich aber auch noch einen SoftwareUART zusätzlich verwenden damit ein PIC zwischen EMS-Bus und PC läuft. Vielleicht wird es ja auch ein externer UART oder auch ein anderer PIC. Im Moment habe ich einen PIC der den EMS-Bus mit CAN verbindet. Der zweite verbindet dann den CAN mit dem PC. Ich bin Assembler Anhänger weil ich kein C kann und mir einbilde dass ich dann mehr Kontrolle über die Hardware habe. Werde später dann den Eagle-Schaltplan und die Firmware als Download anbieten und natürlich eine Art Sammelbestellung machen. Wird vermutlich SMD sein die selber bestückt werden muss. Wenn natürlich genug zusammenkommen würde eine fertig bestückte Platine sich auch rechnen. Das Sollwert vorgeben sollte wirklich kein Problem mehr sein... Die Prüfsumme, das Telegrammformat sind ja soweit eigentlich bekannt... Bin allerdings noch nicht mit meiner Empfangsschaltung zufrieden und werde demnächst mal die gepostete Buderus-Lösung ausprobieren. Vermutlich wird die besser als meine "Standartbeschaltung". Im Moment kämpfe ich noch mit den letzten Feinarbeiten an dem 3964R-Protokoll herum. Werde mich hier auf jedenfall noch mal zu Wort melden wenn eine Sammelbestellung in Sicht ist. Gruß IngoF
Hallo, endlich jemand der einen PIC programmiert. Der 18F2580 hat gegenüber den 18F2550 zwei Nachteile. Es fehlt der USB-Bus sowie die Komperatoreneingänge, diese hat laut Datenblatt nur der große Bruder 18F4580. Falls man diesen nimmt, dann dürfte es mit der EUSART keine Probleme geben. Der Vorteil des 18F2580 ist, daß wenn 32Mhz Taktfrequenz genügen man keine Quarzbeschaltung benötigt, da man den internen Takt über der der PLL hochtreiben kann. Sowie der CAN-Bus. Habe ich es richtig verstanden, daß der CAN-Bus nur für die Verbindung der zwei PIC's genommen wird? Könnte da man nicht den I2C-Bus nehmen oder ist da die Reichweite zu klein. Welche Schnittstelle wird denn zum PC genommen? Eine RS232? Diese Schnittstelle haben die meisten neuen Rechner nicht mehr, hier wäre eine USB-Schnittstelle von Vorteil. Zum EMS-Bus wird wohl die Eusart-Schnittstelle mit dem 3964R Protokoll genommen, welches ich nicht kenne. Von SMD bin ich kein Freund, ich weiß nicht ob ich dies mit einem normalen Lötkolben löten kann. Außerdem, falls man mal was ändert, dann ist die Beschaltung doch sehr klein. Die PIC's habe ich immer mit einen Bootloader, welcher ich mit einen einfachen Brenner programmiert hatte, versehen. Die Firmware hatte ich dann mit den USB-Bus geladen hatte. Pitkit oder ähnliches besitze ich nicht. Assembler ist Ok, ich programmiere zwar mehr in C18 wegen der Übersichtlichkeit, aber schnelle Interruptprogramme habe ich meistens in Assembler geschrieben. Ich bin auf jeden Fall auf den Schaltplan sowie der Firmware interessiert und freue mich wenn eine Sammelbestellung in Sicht ist. Viele Grüße F. F.
Hallo F.F. habe mal einen neuen Thread für dieses Thema gemacht: Beitrag "Buderus EMS-"Gateway" mit PIC18F / Sammelbestellung" Alles zu der Sammelbestellung, Schaltungs- und Softwareentwicklung gibt es dann dort. Hat ja schon lange nichts mehr mit der Buderus 2107 zu tun. Gruß IngoF
Niffko _ schrieb: > achso ... ich habe mal das bus interface eines moduls mm10 aufgedröselt > und zu 'papier' gebracht (siehe anhang). Hallo Niffko, deine Schaltung ist so nicht richtig. An den Eingangskomparator muss an - die Uref. Die 1nF/100k/10k sollten da nicht sein, wofür sind die? Ich habe die Schaltung mal aufgebaut und mit einem Funktionsgenerator getestet und gemessen. Funktioniert ganz ordentlich mit der Änderung. Grüße.
Rudi schrieb: > deine Schaltung ist so nicht richtig. Gut gebrüllt, Löwe. > An den Eingangskomparator muss an - die Uref. Da am (+) Eingang über den 47K Widerstand ebenfalls Uref. anliegt, hättest Du damit IMHO den gleichen Gleichspannungspegel an beiden Eingängen, hältst Du das bei einem Komparator für sinnvoll?! So wie ich das sehe, wird Uref. über einen Spannungsteiler (10K/100K) auf den (-) Eingang gelegt. Somit ist der "Ruhepegel" an (-) geringfügig unterhalb dem von (+) und der Komparator damit definiert auf High. Den 1nF Kondensator sehe ich als eine Art Störunterdrückung. Kurze (Stör)Impulse führen nicht zu einer "Fehlzündung" des Komparators, da die Pegel zunächst an beiden Eingängen abgesenkt werden und somit kein Delta entsteht. Ist der Low-Impuls aber länger als die Umladezeit des 1nf Kondensators, schaltet der Komparator. Soweit meine Theorie ... sollten hier Profis mitlesen, bitte ich ggf. um Berichtigung. Besagte Schaltung arbeitet übrigens in meinem Projekt 'Rücklaufgeführte Heizungsregelung' bereits über mehrere Monate sowohl im Rx- als auch im TX-Betrieb einwandfrei. // Niffko
Niffko _ schrieb: > Rudi schrieb: >> deine Schaltung ist so nicht richtig. > > Gut gebrüllt, Löwe. Ja ;-). Die Signale sehen an +/- in etwa gleich aus, bei dem 1nF Kondensator etwas verzerrter. Ich kann mal Bilder mit dem Oszi machen, wie gesagt ich habe das mit einem Signalgenerator getestet (Offset 9.5V und dann ein 5V Signal) ohne ordentliches Signal am Ausgang. Es gab nur Spikes an den Flanken. Grüße.
Angehängte Dateien:
-
ems_measure.jpg
210 KB
Anbei das Bild. Oben das Signal am 10uF und unten das Signal am 1nF. Wie man sieht kann der Komparator bei diesen Signalen nicht schalten. Niffko _ schrieb: > Da am (+) Eingang über den 47K Widerstand ebenfalls Uref. anliegt, > hättest Du damit IMHO den gleichen Gleichspannungspegel an beiden > Eingängen, hältst Du das bei einem Komparator für sinnvoll?! Der Widerstand arbeitet als Pullup für das Signal am Kondensator, siehe Bild, ansonsten würde der Kondensatorausgang bei DC-Signalen floaten. > So wie ich das sehe, wird Uref. über einen Spannungsteiler (10K/100K) > auf den (-) Eingang gelegt. Somit ist der "Ruhepegel" an (-) geringfügig > unterhalb dem von (+) und der Komparator damit definiert auf High. Auch hier wird das Signal hinter dem Kondensator über die beiden Widerstände konditioniert, siehe Bild, nur ist die Ladung bei diesem Kondensator relativ gering und das Signal fällt relativ schnell ab. > Den 1nF Kondensator sehe ich als eine Art Störunterdrückung. Kurze > (Stör)Impulse führen nicht zu einer "Fehlzündung" des Komparators, da > die Pegel zunächst an beiden Eingängen abgesenkt werden und somit kein > Delta entsteht. Ist der Low-Impuls aber länger als die Umladezeit des > 1nf Kondensators, schaltet der Komparator. Nein. Die Kondensatoren übertragen den AC-Anteil vom Signal. Sprich nur sich ändernde Signale. > Besagte Schaltung arbeitet übrigens in meinem Projekt 'Rücklaufgeführte > Heizungsregelung' bereits über mehrere Monate sowohl im Rx- als auch im > TX-Betrieb einwandfrei. Das ist seltsam. Kannst du die Signale mit einem Oszi. messen? Grüße.
Angehängte Dateien:
-
ems_measure_1_.jpg
200 KB
Hallo Rudi, vorab, die Signalhübe und Offsets unbekannterweise jetzt mal außen vor gelassen - warum schaltet der Komparator nicht spätestens bei Markierung II (siehe Anhang)? Zu diesem Zeitpunkt liegt das Signal an (+) noch auf Low und an (-) ist durch die geringe Kapazität des 1nF Kondensators bereits keine AC-Einkopplung mehr vorhanden. Die Spannung an (+) müsste sich also unterhalb der an (-) befinden, was ein Schalten des Komparators zur Folge hätte. > Niffko _ schrieb: >> ... über den 47K Widerstand ebenfalls Uref. anliegt... > > Der Widerstand arbeitet als Pullup ... Sozusagen. Und auf welche Spannung pullt er up ... auf Uref. > ... als Pullup für das Signal am Kondensator, siehe > Bild, ansonsten würde der Kondensatorausgang bei DC-Signalen floaten. Das ist nicht unrichtig, aus meiner Sicht ist der Hintergrund aber ein anderer. Wie Du richtig angemerkt hast, wird über die Kondensatoren nur der AC-Anteil des Signals eingekoppelt. Durch die Widerstände werden die Eingänge des Komparators auf ein gewisses DC-Niveau vorgespannt - über den Daumen, (+) auf 0,6V und (-) auf 0,55V. Der eingekoppelte AC-Anteil bewirkt dann das Auslösen des Komparators. Beim Anliegen eines Null-Bits gibt es bis zum Schalten des Komparators eine Totzeit (Bereich zwischen I und II), da das Signal zunächst auf beide Eingänge wirkt, die Spannung an (-) durch die schnellere Umladung des 1nF Kondensators aber relativ fix wieder auf 0,55V steigt (siehe Bild). >> So wie ich das sehe, wird Uref. über einen Spannungsteiler (10K/100K) >> auf den (-) Eingang gelegt. > > Auch hier wird das Signal hinter dem Kondensator über die beiden > Widerstände konditioniert, siehe Bild, nur ist die Ladung bei diesem > Kondensator relativ gering und das Signal fällt relativ schnell ab. Wie gesagt, m.E. keine Signalkonditionierung, sondern ein Vorspannen der Komparatoreingänge. >> Den 1nF Kondensator sehe ich als eine Art Störunterdrückung... > > Nein. Die Kondensatoren übertragen den AC-Anteil vom Signal. Sprich nur > sich ändernde Signale. Du hast mich nicht richtig verstanden. Das es hier um AC-Kopplung geht, sollte klar sein. Das Ding ist, dass der 10µ das Signal 1:1 durch reicht, der 1nF aber nur kurze Spikes auf den (-) Eingang koppelt. Daraus ergibt sich eine Art Schaltverzögerung, wodurch kurze Störimpulse dann keinen Schaltvorgang auslösen. >> Besagte Schaltung arbeitet übrigens ... einwandfrei. > > Das ist seltsam. Kannst du die Signale mit einem Oszi. messen? Aus Mangel an einem Funktionsgenerator, könnte ich das nur am Bus machen. Weiß nicht ob das viel Sinn macht. Ist auch alles ziemlich fummelig, da SMD. Mal sehen ... // Niffko Edit sagt: Zumindest ein Kollege aus dem Junkers-Thread scheint die Schaltung auch erfolgreich anzuwenden.
Hallo, Niffko _ schrieb: > vorab, die Signalhübe und Offsets unbekannterweise jetzt mal außen vor > gelassen - warum schaltet der Komparator nicht spätestens bei Markierung > II (siehe Anhang)? Zu diesem Zeitpunkt liegt das Signal an (+) noch auf > Low und an (-) ist durch die geringe Kapazität des 1nF Kondensators > bereits keine AC-Einkopplung mehr vorhanden. Die Spannung an (+) müsste > sich also unterhalb der an (-) befinden, was ein Schalten des > Komparators zur Folge hätte. Ja, wenn der Komparator schnell genug ist sollte man am Ausgang Spikes sehen. Der schaltet den Ausgang auf High wenn das Signal (+) über oder auf Low wenn das Signal unter der Schwelle (-) liegt. Und hier schaltet der nicht weil das Signal nie unter der Schwelle liegt. >> Niffko _ schrieb: >>> ... über den 47K Widerstand ebenfalls Uref. anliegt... >> >> Der Widerstand arbeitet als Pullup ... > > Sozusagen. Und auf welche Spannung pullt er up ... auf Uref. Genau, wenn am Kondensator mal kein Signal anliegt bzw. nur ein High auf dem Bus anliegt, liegt das Signal über der Schwelle und am Ausgang vom Komparator liegt das Signal stabil auf High. Ansonsten würde sich der Kondensator mit der Zeit entladen und gegen 0V laufen, unter die Schwelle und am Ausgang wäre ein Low zu sehen. Das spricht eigentlich dafür, das der Kondensator nicht an das Eingangssignal geht sondern dort an Masse (Blockkondensator) und die beiden Widerstände als Widerstandsteiler arbeiten um die Uref etwas zu senken. Grüße.
Wie ist denn die Spannungsauflösung (V/cm) auf Deinem Oszi-Bild und sind die Offsets real oder hast Du vertikal verschoben? // Niffko
Niffko _ schrieb: > Wie ist denn die Spannungsauflösung (V/cm) auf Deinem Oszi-Bild und sind > die Offsets real oder hast Du vertikal verschoben? Der Auflösung lag bei 200mV, wenn ich mich recht erinnere. Die Offsets sind vertikal verschoben. Ich werde für den RX-Pfad wie bisher den ADCMP370 benutzen, der hat bis jetzt funktioniert und die Bauteile halten sich in Grenzen. Den TX-Pfad werde ich wie bei dir in der Schaltung aufbauen, aber ohne Komparator. Die Versorgung werde ich auf 3V3 legen, aus einem LDO und die Anbindung wird dann Isoliert (ISO7421D). Grüße.
Hallo, Niffko _ schrieb: > Besagte Schaltung arbeitet übrigens in meinem Projekt 'Rücklaufgeführte > Heizungsregelung' bereits über mehrere Monate sowohl im Rx- als auch im > TX-Betrieb einwandfrei. könntest Du dein Projekt etwas näher beschreiben? Ich werde demnächst etwas ähnliches regeln. Leider ist die Heizung z.Z. nicht mehr operational, da in diesem Raum eine Bodensanierung anliegt. Ich will den Rücklauf über einen Speicher anheben, der von der Holzheizung geladen wird und evtl. später auch von Solar. Grüße.
Hi Rudi, Rudi schrieb: > könntest Du dein Projekt etwas näher beschreiben? Ich habe die Heizkreisregelung komplett aus dem RC35 herausgenommen. Die Brenneransteuerung erfolgt im Grunde über zwei Kennlinien - Außentemperatur vs. Rücklaufsolltemperatur und Außentemperatur vs. Brennerleistung. Die Führungsgrößen Rücklauftemperatur und Außentemperatur werden vom Bus genommen, Brenneransteuerung erfolgt über außentemperaturabhängige Vorgabe der Brennerleistung. Für Logging- und Monitorzwecke wird über UART ein Telegramm mit relevanten EMS-Daten bereitgestellt, EMS-Kommunikation läuft über Soft-UART. Momentan bin ich dabei, mit C# eine GUI zu stricken, über die dann Monitoring, Logging(.csv) und Parametrierung des Reglers möglich ist. > Ich will den Rücklauf über einen Speicher anheben, der von der > Holzheizung geladen wird und evtl. später auch von Solar. Hmm ... eigentlich brauchst Du für so was nicht an den EMS-Bus. Macht man üblicherweise mit einem Differenztemperatur-Regler welcher Anlagenrücklauf und Puffertemperatur überwacht. Ist der Anlagenrücklauf kälter als der Puffer, wird er über ein Dreiwegeventil in den Puffer und das Pufferwasser zum Heizkesselrücklauf geführt. Sollte die Puffertemperatur noch nicht deckend sein, heizt der Heizkessel entsprechend seiner Kennlinie nach. //Niffko
Hallo, Niffko _ schrieb: > Hmm ... eigentlich brauchst Du für so was nicht an den EMS-Bus. Macht > man üblicherweise mit einem Differenztemperatur-Regler welcher > Anlagenrücklauf und Puffertemperatur überwacht. Ist der Anlagenrücklauf > kälter als der Puffer, wird er über ein Dreiwegeventil in den Puffer und > das Pufferwasser zum Heizkesselrücklauf geführt. Sollte die > Puffertemperatur noch nicht deckend sein, heizt der Heizkessel > entsprechend seiner Kennlinie nach. Ja, klassische Zweipunktregelung die den Brenner zum oszillieren bringt und ich vermeiden wollte. Ich werde ein "richtiges" Mischerventil benutzen und versuchen den Brenner auf Sparflamme zu fahren und nicht volle Pulle umschalten. Wenn die Speichertemperatur größer als die Sollvorlauftemperatur ist, verbrät mir die Zweipunktregelung zu viel Energie. Grüße.
Hallo :) Hat hier einer eigentlich mal einen längeren Mitschnitt was sich zwischen Servicekey und "Servicebuchse" so tut nachdem man das Teil eingesteckt hat?
Hoch eine Frage bzgl. KM271-Schnittstelle: Habe mir grad mal die "Baupläne" für die Nachbauten angesehen. Wozu benötigt man den Analogpart? UART_RX, UART_TX, GND und +5V reichen doch für die Kommunikation oder?
Fred Granna schrieb: > Hat hier einer eigentlich mal einen längeren Mitschnitt was sich > zwischen Servicekey und "Servicebuchse" so tut nachdem man das Teil > eingesteckt hat? Weiter oben sind doch welche. Das Problem ist eher die Kommunikation bzw. Umsetzung von PC<=>SERVICEKEY. Grüße.
Fred Granna schrieb: > Habe mir grad mal die "Baupläne" für die Nachbauten angesehen. Wozu > benötigt man den Analogpart? UART_RX, UART_TX, GND und +5V reichen doch > für die Kommunikation oder? In der Schaltung wird angeblich(tm) der GND verschoben, also alle Temperaturen stimmen nicht mehr. Desweiteren hat die KM-Platine einen Anschluss für einen Abgassensor. Grüße.
Rudi schrieb: > Weiter oben sind doch welche. Das Problem ist eher die Kommunikation > bzw. Umsetzung von PC<=>SERVICEKEY. > > > Grüße. Hm, bin ich blind? Da habe ich einen Log gefunden. Der ist aber nicht vollständig. PC<->SK ist doch "nur" 3964R. Frage ist eher: Wie setzt der SK da was um.
Rudi schrieb: > In der Schaltung wird angeblich(tm) der GND verschoben, also alle > Temperaturen stimmen nicht mehr. Desweiteren hat die KM-Platine einen > Anschluss für einen Abgassensor. > > > Grüße. ALso könnte der Analogteil eigentlich wegfallen?
Fred Granna schrieb: > ALso könnte der Analogteil eigentlich wegfallen? Die bist mit GND wohl schon direkt am analogen Teil und ohne den Sensor (dein analoger Teil) erkennt er die Platine/Erweiterung nicht. Grüße.
Fred Granna schrieb: > Hm, bin ich blind? Da habe ich einen Log gefunden. Der ist aber nicht > vollständig. PC<->SK ist doch "nur" 3964R. Frage ist eher: Wie setzt der > SK da was um. Beitrag "Re: Logamatic 2107 Schnittstelle" und folgende etwas zerstreut. Grüße.
Rudi schrieb: > Beitrag "Re: Logamatic 2107 Schnittstelle" und folgende etwas > zerstreut. > Das hatte ich gesehen. Das ist aber die Kommunikation PC<->SK in 3964R soweit ich das verstanden habe. WÜrde aber gerne mal sehen was der SK auf dem EMS-Bus treibt.
Ansonsten hier: Beitrag "Re: Logamatic 2107 Schnittstelle" Dort ist ein Log vom Service-Key. Der Key arbeitet selbständig, sammelt die Daten und schickt sie auf Anfrage an den PC. Wie ist bei dir eigentlich der Stand?
Rudi schrieb: > Wie ist bei dir eigentlich der Stand? Hatte nun über 6 Monate meine Bastellösung am laufen: Arduino mit externem UART über i2c. Schwenke grad um auf einen Arduino mit 4 eigenen UARTS. Habe dazu deine Code genommen. Das Lesen vom Bus läuft. Habe nur massive Probleme beim schreiben: Der Code fehlt mir komplett (und das Wissen dazu auch)...
Der TX ist nicht weiter problematisch, da du das sehr schön im RX-Interrupt machen kannst. Kann die UART vom AVR ein Break senden? Mein Handling um auf dem Bus bekannt zu werden sieht in etwa so aus:
1 | dr = rx_data; |
2 | |
3 | /* sending */ |
4 | if ( ems_flag & 1 ) |
5 | {
|
6 | if ( dr == 0x0b ) |
7 | {
|
8 | /* send uart break */ |
9 | } |
10 | ems_flag &= ~1; |
11 | } |
12 | |
13 | if ( ems_cnt == 0 ) |
14 | ems_adr = dr; |
15 | if ( (ems_cnt == 1) && (dr!=0) && (ems_adr&0x80) ) |
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 | } |
Hallo Leute, sorry wenn ich mich hier einmische, aber ich bin über Google in den wohl längsten Thread der Welt geraten :) Stichwörter: "Buderus Protokoll" Ich verstehe nicht so ganz, worum es hier geht, aber vielleicht bewegt ihr euch ja in der Nähe meines Problems. Ich habe hier einen Raumthermostat namens Sieger eS71, innen auf der Platine steht Buderus RC10/RC20. Das Ding ist aber nur halb bestückt, es hat nur eine simple Thermostatfunktion und sonst nichts, und es werden nur zwei der vier Anschlussdrähte benutzt. Auf einem Aufkleber steht "RC10 V1.04 OK". Mein Problem ist, dass ich meine Gasheizung gern ferngesteuert ein- und ausschalten möchte, während aber heißes Wasser immer zur Verfügung stehen soll. Eine Lösung habe ich schon: eine Zusatzelektronik simuliert Knopfdrehungen durch Schalter, die parallel zu den Knopfkontakten liegen. Damit kann ich die Temperatur auf 11° bzw. 30° stellen, was in der Praxis Aus- bzw. Einschalten bedeutet. Ist aber ziemlich aufwändig und nicht gerade elegant. Aus den Impulsen, die mein Oszilloskop an den beiden Steuerdrähten anzeigt, werde ich nicht schlau. Handelt es sich dabei um das Protokoll, das oben erwähnt ist? Ist vielleicht sogar das Know-How vorhanden, wie man die Information "Zimmer ist zu kalt/heiß" auf die Drähte gibt?
Hallo Rudi, Matthias, Mario und IngoF, könnte jemand eine/mehrere µP-Schaltung mit Hex-File zur Decodierung zur Verfügung stellen? Möglichst gängige µProzessoren. Muß kein Layout da sein, mache ich und stelle es hier rein. Muß auch kein Quellcode dabei sein, wer es nicht freigeben will. Hauptsache alle kommen mal weiter mit dem EMS-Bus. Gruß Helmut
Hallo Helmut, bei mir läuft das Ding wie Stand 1,5 Jahre und ich nehme es nur zum Loggen. Verwendet wird der Pollin NetIo (Atmega644), auf dem ich mich per Telnet von meiner Haussteuerung verbinde. Das Protokoll schicke ich ASCII-kodiert rüber und parse es auf der Steuerung. Empfangen wird mit der kleinen Schaltung ähnlich Rudi (aber mit LM393). Softwarebasis ist der Webserver von U. Radig mit der Empfangsroutine von Rudi und einigen Anpassungen. Problem am Hex ist, das die IP fest einprogrammiert ist. Den Code kann ich gerne posten. Ich krame den am Wochenende mal wieder aus. Das Modul läuft schön stabil, hatte in der ganzen Zeit vielleich 2..3 Hänger nach kurzen Netzspannungseinbrüchen. @all Interessieren würde mich, das EM10-Modul nachzubauen. Kennt da jemand ansatzweise das Protokoll? Weiß jemand, ob/wie man das Signal zur einmaligen WW-Aufheizung abschicken kann? Grüsse Matthias
Danke Dir Matthias, ich habe gar kein Auto.... Ich oute mich mal, ich habe so eine Buderus-Steuerung nicht, auch kein E-Bus-Gerät, wofür der Adapter eigentlich gedacht war. Ich sah nur, dass es Ähnlichkeiten beim Bussystem gibt. Dann hat mich gestört, das es 890 Eintragungen gibt aber keine Lösung, die als brauchbar erkennbar ist. Das muß doch mal fertig werden. Es gibt soviele Anwender für den EMS-Bus. Wäre nett von Dir: Bitte poste Deine Hard und Software. Gruß Helmut
Helmut schrieb: > Dann hat mich gestört, das es 890 Eintragungen gibt aber keine Lösung, > die als brauchbar erkennbar ist. Wie jetzt?
Angehängte Dateien:
-
Modul.jpg
120 KB
Endlich ... es gibt jetzt ein Buderus EMS-Schnittstellenmodul mit USB-Anschluss. //Niffko
Angehängte Dateien:
-
EMS_Interface.jpg
190 KB
... gibts aber leider nur einmal als Prototyp ;P Ich hatte ein defektes Solarmodul SM10 in die Hände bekommen, welches hier als Organspender diente. Als Defektursache war ein zerstörter Komparator der Eingangsbeschaltung relativ schnell ausfindig gemacht und ausgetauscht. Anschließend alles, außer Signalformung, Quarz, LED, Spannungsversorgung und 230V-Peripherie, von der Platine geräumt. Atmega8 und FT323RL wurden rücklinks auf der Platine befestigt und mit AWG#30 Kabel angeschlossen. Der 0.65mm Pitch des FT232 war hierbei - sagen wir mal - anspruchsvoll. Auf der Platine sind mehr Kabel als man eigentlich vermuten sollte, aber das meiste ist hier GND und VCC - hiervon gibts ja bei SMD-Ausführung immer reichlich Pins und an ein Brücken direkt am IC war nicht zu denken. Zum Schluss noch eine Mini-USB Buchse aufgelötet und fertig war meine Hardware für die kommende Heizsaison. //Niffko
Tolle Sache, nur warum zeigst Du sowas? Bringt niemanden so richtig weiter. Einer von 816 Beiträgen mit Null Ergebniss. Oder glaubst Du dass regt jemanden an es auch so zu machen? Ich verstehe es nicht, wenn wenigstens ein Schaltplan dabei gewesen wäre... Oder ein Hex-File eines Prozessors für die Filterung von plausiblen Daten......
Hallo Leute! Mein umgebautes Solarmodul läuft ab sofort 'buspowered'. Schaltung wie folgt:
1 | 120R _____ |
2 | ___ | | |
3 | Bus(+) ---|___|--o--|78L05|--o-----o---- VCC |
4 | | |_____| | | + |
5 | --- | --- ### |
6 | --- | --- --- |
7 | |100n | |100n | 22µ |
8 | | | | | |
9 | === === === === |
10 | GND GND GND GND |
Versorgt wird ein Atmega8 incl. TX-LED. FT232 läuft von der Versorgung über USB und der LM393 hängt direkt am EMS-Bus. Bei permanent eingeschalteter LED fließen ca. 17mA. Busstörungen habe ich bisher keine erkennen können, das Gerät arbeitet wie gewohnt. Das bedeutet eigentlich, dass in Sachen Potentialtrennung auch Optokoppler möglich sein sollten. //Niffko
hallo, habe letzte woche diesen thread per google gefunden und bin echt erstaunt über eure erkenntnisse zum ems-bus. besten dank dafür! daraufhin habe ich jetzt auch zwei tage bastelt und möchte auch meine ergebnisse nicht vorenthalten. ich habe hier noch einen rc20 controller rumliegen gehabt, an dem ich die rx und tx leitung eines sparkfun ftdi board angeschlossen habe, um auf den bus zuzugreifen. die tx-leitung des rc20 microcontrollers habe ich gekappt, um mit dem ftdi board auch schreiben zu können. das ftdi board ist per usb an einem linux pc angeschlossen. dort habe ich ein perl script gebaut, um das polling für die adresse 0xb (service key) zu beantwortet. für das break ziehe ich mit der dtr leitung per transistror den tx-pin für den nötige dauer auf gnd. der service key wird nun bus-monitor angezeigt und ein umschalten von nacht/tag/auto betrieb des rc30 funktioniert schon damit. falls jemand interesse an details hat, dann einfach melden. besten dank, picknicker
Hallo Helmut, ich bin seit einer Woche Besitzer einer Logamatic 172 Anlage. Da ich ein neugierer Mensch bin, würde auch ich gern die Daten der Anlage via EMS-Bus mitloggen. Du scheinst so eine ähnliche Konfiguration am Start zu haben, wie ich Sie gerne hätte. Magst Du mir bitte Deine Schaltung und Deinen Kode für das Pollin NetIo (Atmega644) Board zur Verfügung stellen ? Ist es ein Problem, das meine Anlage mit einem Solarmodul ausgestattet ist ? Ich meine hierzu etwas gelesen zu haben. Viele Grüße Jörg > Hallo Helmut, > > bei mir läuft das Ding wie Stand 1,5 Jahre und ich nehme es nur zum > Loggen. > Verwendet wird der Pollin NetIo (Atmega644), auf dem ich mich per Telnet > von meiner Haussteuerung verbinde. Das Protokoll schicke ich > ASCII-kodiert rüber und parse es auf der Steuerung. Empfangen wird mit > der kleinen Schaltung ähnlich Rudi (aber mit LM393). > Softwarebasis ist der Webserver von U. Radig mit der Empfangsroutine von > Rudi und einigen Anpassungen. Problem am Hex ist, das die IP fest > einprogrammiert ist. Den Code kann ich gerne posten. Ich krame den am > Wochenende mal wieder aus. > Das Modul läuft schön stabil, hatte in der ganzen Zeit vielleich 2..3 > Hänger nach kurzen Netzspannungseinbrüchen.
Ich würde auch gerne mitmachen. Hab auch ein Pollin AVR-Net-IO. Da finden sich bestimmt noch mehr Leute mit Interesse. Ich habe eine Buderus GB152-Therme und würde gerne mitloggen. Viele Grüße Norbert > Hallo Helmut, > ich bin seit einer Woche Besitzer einer Logamatic 172 Anlage. > Da ich ein neugierer Mensch bin, würde auch ich gern > die Daten der Anlage via EMS-Bus mitloggen. > Du scheinst so eine ähnliche Konfiguration am Start zu > haben, wie ich Sie gerne hätte. > Magst Du mir bitte Deine Schaltung und Deinen Kode > für das Pollin NetIo (Atmega644) Board zur Verfügung > stellen ? > > Ist es ein Problem, das meine Anlage mit einem Solarmodul > ausgestattet ist ? Ich meine hierzu etwas gelesen zu haben. > > Viele Grüße > Jörg > >> Hallo Helmut, >> >> bei mir läuft das Ding wie Stand 1,5 Jahre und ich nehme es nur zum >> Loggen. >> Verwendet wird der Pollin NetIo (Atmega644), auf dem ich mich per Telnet >> von meiner Haussteuerung verbinde. Das Protokoll schicke ich >> ASCII-kodiert rüber und parse es auf der Steuerung. Empfangen wird mit >> der kleinen Schaltung ähnlich Rudi (aber mit LM393). >> Softwarebasis ist der Webserver von U. Radig mit der Empfangsroutine von >> Rudi und einigen Anpassungen. Problem am Hex ist, das die IP fest >> einprogrammiert ist. Den Code kann ich gerne posten. Ich krame den am >> Wochenende mal wieder aus. >> Das Modul läuft schön stabil, hatte in der ganzen Zeit vielleich 2..3 >> Hänger nach kurzen Netzspannungseinbrüchen.
Hallo, zunächst einmal: Respekt an alle, die hier mitgewirkt haben! Ich bin recht neu in Sachen Elektronik und deshalb mag folgende Frage auch bei einigen von euch zu Stirnrunzeln führen: Ich würde gerne den ServiceKey Ausgang nutzen um an den Bus zu kommen. Jedoch würde ich hier gerne per Optokoppler galvanisch trennen. Mein eigentliches Problem ist jetzt, dass an diesem Klinkenstecker nur 2x GND und einmal das Signal anliegen. Nur einmal angenommen, ich schalte direkt hinter den Bus einen Operationsverstärker als Impedanzwandler für das Signal(der spätere Aufbau ist anders aber das Beispiel hier reicht), woher kann ich dann die Versorgungsspannung für den Operationsverstärker beziehen? GND kann ich hier zwar anschließend, aber mir "fehlt" in meinem Gedankenkonstrukt dann entweder VCC(>12V), oder, wenn ich die GND vom Klinkenstecker als VCC für den Optopkoppler nehme, ein zweites GND(<12V) für an den Optokoppler. Wenn ich für dieses zweite GND die 0V meiner dahinterliegenden, galvanisch getrennten Schaltung verwenden würde, wäre diese Trennung ja wieder hinfällig? Müsste ich hier noch einmal separat sonst wo an der Heizung etwas abgreifen? Das wäre mehr als unschön. Desweiteren: Kann der Bus genug Strom liefern um meinen Optokoppler zu versorgen? So wie ich das Ganze bisher verstanden habe, scheint er ja belastbar genug zu sein. Ich hoffe man kann das halbwegs nachvollziehen was mein Problem ist.. Danke schonmal! :) Gruß Olaf
OlafTezlaf schrieb: > Ich würde gerne den ServiceKey Ausgang nutzen um an den Bus zu kommen. > Jedoch würde ich hier gerne per Optokoppler galvanisch trennen. Mein > eigentliches Problem ist jetzt, dass an diesem Klinkenstecker nur 2x GND > und einmal das Signal anliegen. Hm? An meinem Klickenstecker hab ich 12V,SIGNAL und GND. Benutze die 12V auch um meine Schaltung inkl. dem Funksender für die Daten zu betreiben. Was für eine Anlage hast du denn?
Fred Granna schrieb: > Hm? An meinem Klickenstecker hab ich 12V,SIGNAL und GND. Benutze die 12V > auch um meine Schaltung inkl. dem Funksender für die Daten zu betreiben. > Ohje, sagt jetzt nicht ich hab die Belegung des Klinkensteckers missverstanden. Ich habe mich auf http://wiki.neo-soft.org/index.php/Heizungsschnittstelle/ServiceKey bezogen. Dann hat das GND bei dem Eintrag unter "links" wohl nichts mit dem GND +12V zu tun? Hatte das ganze jetzt gar nicht nachgemessen. > Was für eine Anlage hast du denn? Mir ist die genaue Kennung leider entfallen, werde nachschauen sobald ich wieder in der Heimat bin. Aber falls ich diese Tabelle missverstanden habe hat es sich damit wohl gelöst :) Gruß Olaf
OlafTezlaf schrieb: > Ohje, sagt jetzt nicht ich hab die Belegung des Klinkensteckers > missverstanden. Ich habe mich auf > http://wiki.neo-soft.org/index.php/Heizungsschnitt... > bezogen. Dann hat das GND bei dem Eintrag unter "links" wohl nichts mit > dem GND +12V zu tun? > Hatte das ganze jetzt gar nicht nachgemessen. Ah! Ja, in der Tabelle hast du auf der linken Seite die STECKERBELEGUNG des Klinkensteckers. Auf der rechten Seite dann eben das was anliegt.
Matthias schrieb: > Den Code kann ich gerne posten. Servus Matthias, ...habe ich was übersehen ;-) Danke im Voraus! Gruß aus der Wetterau Karl M.
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
Hallo Matthias, ... das war flott :) Na, dann wollen wir mal ein bisschen Basteln! Danke nochmal! Gruß Karl M.
Weil wir gerade beim Posten von Code sind, hier mal noch meine Lösung. Die Empfangshardware entspricht weitestgehend der von Ingo geposteten EMSlog.gif (hab noch ein paar zusätzliche LEDs). Die Daten werden von einem auf einem Plug-Computer laufenden Daemon (C++ + Boost, siehe Anhang) übernommen und in eine MySQL-DB geschrieben. Die Telegramm-Auswertung in meinem Daemon sollte das Wissen dieses Threads komplett wiederspiegeln - wenn jemand noch etwas fehlendes sieht, bitte Bescheid sagen ;-)
Danny Baumann schrieb: > Die Empfangshardware entspricht weitestgehend der von Ingo geposteten > EMSlog.gif (hab noch ein paar zusätzliche LEDs). Hallo Danny, liest sich sehr interessant, Dein Projekt. Gibt's denn zu der Verschaltung des ATmega 8 und der Eingangsstufe auch eine Schaltplanskizze? Noch ne Frage: "Den PlugPC hast Du als 'reinen EMS-PC' in Deinem HWR und fragst über LAN die Daten ab?" Vielen Dank für Deine Arbeit! Gruß aus der Wetterau Karl M.
Hi, > liest sich sehr interessant, Dein Projekt. > > Gibt's denn zu der Verschaltung des ATmega 8 und der Eingangsstufe auch > eine Schaltplanskizze? Hab ich jetzt nicht sofort zur Hand, ich kann aber nochmal kramen. Meine Schaltung ist aber - wie gesagt - praktisch die selbe wie die EMSlog.gif hier im Thread. > Noch ne Frage: "Den PlugPC hast Du als 'reinen EMS-PC' in Deinem HWR und > fragst über LAN die Daten ab?" Nein. Der Plug-PC ist mein 'Home-Server', d.h. unter anderem auch File-, Print- und Musik-(Squeezebox-)Server. Den EMS-Daemon und die MySQL-DB frühstückt der nebenbei mit ab ;-) Der Apache, mit dem ich mit etwas gehacktem PHP die Daten anzeige, läuft da auch drauf. Der Plug-PC ist ja hardwaremäßig auch recht gut ausgestattet: http://de.wikipedia.org/wiki/SheevaPlug ... und das bei ~4W Stromverbrauch.
Hallo, versuche schon einige Zeit die Induktivitäten L3/L4 auf zu finden. Es wurde ja schon mal vermutet dass es 4700µH sind. Allerdings sind die größten induktivitäten die ich finden konnte nur 1000µF. Jetzt habe ich irgendwo eine Induktivität gefunden die mit 472K in der Bezeichnung trägt und 47µ bei 1kHz hat. Hier noch mal der Link zum Bild: Beitrag "Re: Logamatic 2107 Schnittstelle" Was habt Ihr denn für die Spule L3/L4 genommen? Gruß Ingo
Hallo Ingo, Du musst nach "4,7 mH" und nicht nach "4700 uH" suchen: http://www.segor.de/#Q=4,7mH-09P Festinduktivität 4,7mH +/-5% 130mA 11,5R RM5 http://www.segor.de/#Q=4,7mH-SD75 Festinduktivität 4,7mH +/-10% 70mA 48R RM5 oder bei Conrad Best.-Nr.: 535508 - 62 bzw 501596 - 62 http://www.conrad.de/ce/de/product/535508/DROSSEL-47-MH/SHOP_AREA_17429&promotionareaSearchDetail=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
Hallo, warum benutzt du nicht einfach Ferritbeads? Die sollten die Störungen auch ausreichend unterdrücken. Grüße.
Hallo Danny,
> ich kann aber nochmal kramen
schon gekramt? Falls ich Deinen Quelltext im framer richtig
interpretiere, ist Deine Belegung anders als in der EMS-log.gif?
Beim compilieren des collectors hatte ich zunächst eine fehlende
"common.h". Da ich vermutete, dass es sich hierbei um die common.h aus
"mysql++" handelt, habe ich dorthin gelinkt. Jetzt ergibt ein "make all"
folgenden Fehlertext:
Message.cpp: In member function ‘virtual void StatsMessage::parse()’:
Message.cpp:481: error: ‘rx_stats_t’ was not declared in this scope
Message.cpp:481: error: expected ‘;’ before ‘stats’
Message.cpp:487: error: ‘stats’ was not declared in this scope
make: *** [Message.o] Fehler 1
Meine config hier:
VirtualBox-4.1.6 mit Debian-6.02, Kernel 2.6.32 mit installiertem
libboost, mysql, libmysql++ und build-essential.
Irgendeine Idee, was ich hier falsch mache?
Danke im Voraus und Grüße aus der Wetterau
Karl M.
charlie schrieb: > Hallo Danny, > >> ich kann aber nochmal kramen > > schon gekramt? Nein, noch nicht. Ich versuche heute abend mal dran zu denken. > Falls ich Deinen Quelltext im framer richtig > interpretiere, ist Deine Belegung anders als in der EMS-log.gif? Das könnte sein ... evtl. hab ich die Belegung so angepasst, dass die Verdrahtung einfacher ist. > Beim compilieren des collectors hatte ich zunächst eine fehlende > "common.h". Da ich vermutete, dass es sich hierbei um die common.h aus > "mysql++" handelt, habe ich dorthin gelinkt. Jetzt ergibt ein "make all" > folgenden Fehlertext: > > Message.cpp: In member function ‘virtual void StatsMessage::parse()’: > Message.cpp:481: error: ‘rx_stats_t’ was not declared in this scope > Message.cpp:481: error: expected ‘;’ before ‘stats’ > Message.cpp:487: error: ‘stats’ was not declared in this scope > make: *** [Message.o] Fehler 1 common.h ist in framer/ - siehe collector/Makefile, Zeile 2. Danny
Danny Baumann schrieb: > common.h ist in framer/ - siehe collector/Makefile, Zeile 2. jetzt wo Du es sagst :-*) - Läuft einwandfrei durch, tolle Arbeit! Über den Schaltplan würd' ich mich freuen :-) Vielen Dank für Deine Geduld! Gruß Karl M.
Michael Dreher schrieb: > Du musst nach "4,7 mH" Habe ich natürlich auch. Aber alles was ich finde ging nur bis 1mH. Die Bauteile habe ich auch gefunden. Suche allerdings die SMD-Versionen. Die Suche bei Conrad ist sowieso absolut unbrauchbar. Man kann nicht nach einem Wert suchen, sondern nur alle SMD-Induktivitäten durchsuchen. Dummerweise steht dann überall in der Überschrift 1-1000µH. Bei anderen Herstellen habe ich auch keine SMD-Versionen gefunden. Oder die liefern nur an Gewerbliche Kunden und nicht an Endabnehmer. vielleicht nehme ich dann doch die Nicht-SMD-Induktivitäten. Rudi schrieb: > warum benutzt du nicht einfach Ferritbeads? Die sollten die Störungen > auch ausreichend unterdrücken. Muss gestehen dass ich von Entstörung nicht soviel Ahnung habe. Habe auch keine Messtechnik um dabei Unterschiede selber zu sehen. Wenn Buderus ja so eine Schaltung hat würde ich die schon gerne klauen ;o) Bei der RC 30 sind ja erst kleiner Induktivitäten und dann die großen. Dazwischen ist eine Durchkontaktierung und kann selbst beim durchleuchten eine Leiterbahn erkennen. Vermute mal dass dazwischen der Abriff für die Sende/Empfangsschaltung ist und hinter den Spulen nur der Abgriff für die Spannungs/Stromversorgung ist und die Induktivitäten den "Einschaltstrom" der Bufferkondensatoren vom 78L05 begrenzen sollen. Gruß Ingo
Ingo F. schrieb: > Vermute mal dass dazwischen der Abriff für die Sende/Empfangsschaltung > ist und hinter den Spulen nur der Abgriff für die > Spannungs/Stromversorgung ist und die Induktivitäten den > "Einschaltstrom" der Bufferkondensatoren vom 78L05 begrenzen sollen. Okay, beim Einschaltstrom macht es natürlich Sinn. Kann das mal jemand für die originale Schaltung berechnen? :-). Was brauchst du denn genau (was hast du gefunden) in SMD? Grüße.
Hi Ingo, als ich die Schaltung seinerzeit reverseingeneered habe, hatte ich Probleme die Induktivität zu identifizieren. Du hast ja auch schon gemerkt, dass es hierzu im Netz widersprüchlich Angaben gibt. Ich hatte mir die Teile aber von einem defekten Modul ausgelötet und deshalb war der Leidensdruck für eine Recherche bis zum Letzten nicht groß genug. Das habe ich jetzt nachgeholt und mein jetziger Wissensstand ist folgender: 472 -> 4700µH -> 4,7mH 472K -> 4700nH -> 4,7µH Die Induktivitäten dürften somit nur 4,7µH haben. Der mit einem Multimeter gemessen DC-Widerstand von 0.5 Ohm passt dann auch eher. So ... ich geh' dann mal, mir etwas Asche aufs Haupt streuen. //Niffko PS: An deine Theorie "Einschaltstrom, Kondensator, 78L05" glaube ich nicht so recht. Die Buderus Module haben alle ein separates Netzteil - sind also nicht buspowered - und haben trotzdem auch eine kleine und eine große Induktivität.
Niffko _ schrieb: > Die Induktivitäten dürften somit nur 4,7µH haben. Der mit einem > Multimeter gemessen DC-Widerstand von 0.5 Ohm passt dann auch eher. Niffko _ schrieb: > Die Induktivitäten dürften somit nur 4,7µH haben. Na das beruhigt mich ja schon mal... Und deswegen kann ich seit einem Monat nicht schlafen :oD Niffko _ schrieb: > PS: An deine Theorie "Einschaltstrom, Kondensator, 78L05" glaube ich > nicht so recht. Die Buderus Module haben alle ein separates Netzteil - > sind also nicht buspowered - und haben trotzdem auch eine kleine und > eine große Induktivität. Habe leider keine Buderus Module. konnte nur von der RC30 ausgehen die ich an der Wand hängen hatte. War nur eine Vermutung warum es zwischen den Spulen einen Abgriff gibt.... Rudi schrieb: > Was brauchst du denn genau > (was hast du gefunden) in SMD? Hatte diese hier gefunden.... Allerdings steht nur in der Titelzeile 4,7mH. In der Beschreibung steht auch nur 4,7µH... Also habe ich dann doch keine gefunden... Gruß Ingo
Hallo, Ingo F. schrieb: > Hatte diese hier gefunden.... Allerdings steht nur in der Titelzeile > 4,7mH. In der Beschreibung steht auch nur 4,7µH... > > Also habe ich dann doch keine gefunden... Wie sieht es mit der LB2012T4R7M => 0805, 4.7µH, 190mA, 0,10€ CB2012T4R7M => 0805, 4.7µH, 580mA, 0,15€ aus? Grüße.
Hallo zusammen, hat schonmal jemand versucht einer Logamatic 4xxx Daten zu entlocken? Kennt jemand die Pinbelegung der 15-pol. HD-Sub-D-Buchse (sieht aus wie eine VGA-Buchse)? Kann ich davon ausgehen, dass das Protokoll ähnlich ist wie bei der RC30/35? Immerhin passt hier ja auch der Service Key über einen beiliegenden HD-Sub-D-Klinken-Adapter. Falls das so ist, will ich mir einen möglichst einfachen Pegelwandler bauen. Ich denke das müsste auch ohne Komparator gehen. Ich würde einfach einen PNP-Transistor nehmen, dessen Basis an die Datenleitung hängen, den Emitter über einen 1k Widerstand an 12V und den Collector über einen 3.3k Widerstand an Masse. Der Ausgang für die RS232 Schnittstelle wäre dann der Collector. Wenn auf der Datenleitung 12V+/-2V anliegen, sollten so am Ausgang ca. 5V oder 0V anliegen, was auch für die RS232 Schnittstelle in Empfangsrichtung ausreichen sollte. Evtl. muss man noch einen Inverter vorsehen, falls die Polarität nicht stimmt. Kann das wirklich so einfach gehen, oder mache ich einen Denkfehler? Gruß Sebastian
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
Niffko, danke für die Info. Was ich bisher verstanden habe ist, dass es zwei unterschiedliche Protokolle gibt: EMS und ECO-CAN. Intern spricht die Logamatic 4xxx wohl ECO-CAN, aber die Verbindung zur Fernbedienung BFU läuft über EMS. Möglicherweise gibt es eine Art eingebauten Umsetzer zw. EMS und ECO-CAN. Dann könnte u.U. auch der Service Key EMS sprechen. Ich habe eine BFU in Betrieb. Könnte ich über die Verbindung zur BFU an alle Daten kommen, oder ist zu erwarten, dass nur für den Heizkreis relevante Daten übertragen werden, dem die BFU zugeordnet ist? Gruß Sebastian
Morus schrieb: > ... Logamatic 4xxx ... die Verbindung zur Fernbedienung > BFU läuft über EMS. Das ist sehr unwahrscheinlich, da es die 4000er schon gab, als an EMS noch nicht zu denken war. Die Schnittstelle ECO-CAN / EMS wird über Funktionsmodule realisiert, mit denen man, je nach verwendetem Modul, bis zu zwei oder bis zu 4 EMS-Kessel kaskadieren kann. Die kleinen Wandschaltkästen wie z.B. Logamatic 41XX, besitzen eine interne Schnittstellenkarte für eine Einzelkesselsteuerung, die übrigens auch mit Pre-EMS-Wandkesseln (UBA1.5) kommuniziert. //Niffko
Niffko _ schrieb: > Das ist sehr unwahrscheinlich, da es die 4000er schon gab, als an EMS > noch nicht zu denken war. Ok, dann hab ich da was falsch verstanden. Physikalisch scheint das Protokoll zur BFU aber ähnlich zu EMS zu sein, d.h. 12V+-2V. Gruß Morus
Ein Hallo an alle Experten, ich habe die ganzen Informationen aufmerksam durchgelesen und dabei sehr viel erfahren. Ich habe eine LogamaxPlus GB142 mit den Basiscontroller RC10 und der RC30 mit Außentemperatursteuerung. Habe jetzt eine Solaranlage mit Pufferspeicher einbauen lassen und möchte anstelle der RC30 eine UVR1611 Regelung verwenden. Was mir fehlt ist die PIN Belegung des 81 pin Konnektor in der GB142 Kann mir jemand schreiben wo ich die PIN Belegung herbekomme? Sollte ich hier im Forum nicht richtig sein, bitte ich um Nachsicht. Viele Grüße JoSt
Moin, na was wird gesendet? Zeig doch mal. Grüße. Morus schrieb: > Niffko _ schrieb: >> Das ist sehr unwahrscheinlich, da es die 4000er schon gab, als an EMS >> noch nicht zu denken war. > > Ok, dann hab ich da was falsch verstanden. Physikalisch scheint das > Protokoll zur BFU aber ähnlich zu EMS zu sein, d.h. 12V+-2V. > > Gruß > Morus
Jo Stetter schrieb: > ... anstelle der RC30 eine UVR1611 Regelung verwenden. > Was mir fehlt ist die PIN Belegung des 81 pin Konnektor in der GB142 ... Welche Anschlussmöglichkeiten gedenkst du denn am 81 pin Konnektor zu finden? Dass dort sämtliche Sensoren und die Niederspannungsperipherie - wie z.B. die Gasarmatur - angeschlossen und das Ganze somit sicherheitsrelevant ist, weißt du ja sicherlich schon!? Das Hauptproblem wird werden, den Brenner der GB142 mit der UVR modulierend zu betreiben. Hierfür ist ist zwingend erforderlich, dem Feuerungsautomaten (UBA3) per EMS-Bus einen entsprechenden Sollwert zu übermitteln. //Niffko
Guten morgen, ich hab jetzt einiges aus diesem riesen Thread gelesen, bin aber noch nicht so richtig schlau. Welche Schaltung ist denn 'die Beste' für die Verbindung der Service-Key Schnittstelle mit einem Controller bzw. Pegelwandler auf RS232? Gruss Norbert
Hallo Norbert. ich würde mal sagen diese hier: Beitrag "Re: Logamatic 2107 Schnittstelle" die ist aus einer Schaltung von Buderus und habe ich in meinem EMS-Gateway auch übernommen... Gruß IngoF
Ingo F. schrieb: > Hallo Norbert. > > ich würde mal sagen diese hier: > Beitrag "Re: Logamatic 2107 Schnittstelle" > > die ist aus einer Schaltung von Buderus und habe ich in meinem > EMS-Gateway auch übernommen... Allerdings sind auch Rudi's Kommentare dazu zu beachten: Beitrag "Re: Logamatic 2107 Schnittstelle" Die Originalschaltung scheint bei mir nicht so gut zu funktionieren (Tastverhältnis zwischen Bus-Signal und Komparator-Ausgang verschiebt sich stark) - zeigt sich bei mir darin, dass ich viele CRC-Fehler sehe. Mit Rudi's Änderung sieht das Tastverhältnis deutlich besser aus, ich hab's allerdings noch nicht am Bus getestet.
Danny Baumann schrieb: > (Tastverhältnis zwischen Bus-Signal und Komparator-Ausgang verschiebt > sich stark) - zeigt sich bei mir darin, dass ich viele CRC-Fehler sehe. Das Tastverhältnis sollte sich dahingehend ändern, dass der Low-Pegel etwas verspätet durchkommt - das unterdrückt Störsignale die deutlich unterhalb einer Bitlänge liegen. Zu Datenfehlern sollte das aber nicht führen. Ist evtl. mit deinen Kondensatoren (1nF/10µF) etwas nicht in Ordnung - für den 10µ einen ungepolten Typ verwendet? //Niffko
> Danny Baumann schrieb: >> (Tastverhältnis zwischen Bus-Signal und Komparator-Ausgang verschiebt >> sich stark) - zeigt sich bei mir darin, dass ich viele CRC-Fehler sehe. > > Das Tastverhältnis sollte sich dahingehend ändern, dass der Low-Pegel > etwas verspätet durchkommt - das unterdrückt Störsignale die deutlich > unterhalb einer Bitlänge liegen. Zu Datenfehlern sollte das aber nicht > führen. Ist evtl. mit deinen Kondensatoren (1nF/10µF) etwas nicht in > Ordnung - für den 10µ einen ungepolten Typ verwendet? Ja, ist ein ungepolter Typ, und ja, das Tastverhältnis ändert sich dahingehend, dass bei einem 50%-Rechteck am Eingang High so um die 70% bekommt. Mit Rudi's Änderung sind's 60%. Ich hab das allerdings auch noch nicht zu Ende debuggt (hab die Platine erst gestern bekommen) und nur gesehen, was mir meine LEDs anzeigen. Wenn mein Code komplett fertig ist, sag ich nochmal Bescheid ;)
War denn die Signalform mit der Originalschaltung o.k.? Rudi hatte ja seinerzeit die Änderung vorgenommen, weil er nur Spikes am Komparatorausgang hatte. //Niffko
Niffko _ schrieb: > War denn die Signalform mit der Originalschaltung o.k.? Rudi hatte ja > seinerzeit die Änderung vorgenommen, weil er nur Spikes am > Komparatorausgang hatte. Ja, Signalform war sauberes Rechteck. Ich werd's jetzt mit der umgebauten Schaltung testen; sobald ich sehe, dass ich sinnvolle Werte einlese (die CRC-Fehler können schließlich auch in meinem Code entstehen), bau ich die Schaltung wieder zurück und probier nochmal.
Danny Baumann schrieb: > Ich werd's jetzt mit der umgebauten Schaltung testen; sobald ich sehe, > dass ich sinnvolle Werte einlese (die CRC-Fehler können schließlich auch > in meinem Code entstehen), bau ich die Schaltung wieder zurück und > probier nochmal. Ok, ich hab's jetzt mal mit einer normalen (PC-)UART getestet - der Code ist einwandfrei. Das Signal am Komparator sieht auch exakt so aus, wie man es erwarten würde (Dauer für die 2 Pollbytes 2.1ms, erst ein Datenbyte, dann Low-Pegel). Da mein Board (Pollin NetIO) ohne EMS-Zusatzplatine (oder mit Zusatzplatine, aber ohne angeschlossenen EMS) einwandfrei funktioniert und sich sofort nach dem Anschließen komisch verhält (z.B. massive Paketverluste am Ethernet), liegt ein Masseproblem o.Ä. nahe. Meine Schaltung ist die von Niffko gepostete Buderus-Schaltung. +5V und GND kommen vom Pollin-Board, RX und TX gehen vom Komparator an die USART1 des Atmega644p. Hat einer von euch eine Idee, was da elektrisch schief laufen könnte? Wie habt ihr die Massetrennung gelöst? Ethernet-Masse und Gleichspannungsmasse habe ich auf dem NetIO schon mit 1nF getrennt (sind normalerweise zusammengeklemmt), hat aber leider nix gebracht. Danke, Danny
Danny Baumann schrieb: > Meine Schaltung ist die von Niffko gepostete Buderus-Schaltung. +5V und > GND kommen vom Pollin-Board, RX und TX gehen vom Komparator an die > USART1 des Atmega644p. > Hat einer von euch eine Idee, was da elektrisch schief laufen könnte? > Wie habt ihr die Massetrennung gelöst? Ethernet-Masse und > Gleichspannungsmasse habe ich auf dem NetIO schon mit 1nF getrennt (sind > normalerweise zusammengeklemmt), hat aber leider nix gebracht. Tja, da gab es mit einer anderen Netzwerklösung und einer anderen Heizung auch schon Probleme, in diesem Thread. Der Mantel vom Netzwerk sollte mit einem C oder erstmal garnicht verbunden werden. Die restlichen Leitungen gehen "normal" an einen Übertrager, dann an den FEC und erst dann an den uC. Der Übertrager und FEC sollten den uC ausreichend vom Netz trennen. Wer weiß welche Macken das Board so hat, vom 644 und Netzwerk mal ganz abgesehen, wobei es auch nur die Schmerzgrenze vom Benutzer zeigt ;-). Grüße.
Rudi schrieb: > Tja, da gab es mit einer anderen Netzwerklösung und einer anderen > Heizung auch schon Probleme, in diesem Thread. Der Mantel vom Netzwerk > sollte mit einem C oder erstmal garnicht verbunden werden. Die > restlichen Leitungen gehen "normal" an einen Übertrager, dann an den FEC > und erst dann an den uC. Der Übertrager und FEC sollten den uC > ausreichend vom Netz trennen. Die Ethernet-Schirmung ist ja, wie schon geschrieben, mit 1nF von der Masse getrennt. Ich habe allerdings in der Zwischenzeit festgestellt, dass meine Hypothese "Masseproblem" wirklich nur eine Hypothese war: Ein Softwarebug hat dafür gesorgt, dass der Frame Error nicht erkannt wurde, was einen weiteren Bug getriggert hat (Buffer Overrun), der das komische Verhalten verursacht hat ;) Ich hab jetzt noch ein paar CRC-Fehler drin, da muss ich aber erst mal schauen, ob das eventuell auch nur Softwareprobleme sind. Eine Frage noch zum Polling: Muss ich, wenn ich 0x0b als Antwort gesendet habe, vor dem Senden des Break auf ein Echo des gesendeten Bytes warten oder nicht? Die Aussagen im Thread sind da etwas widersprüchlich...im Moment warte ich nicht, sehe aber Adresse 11 nicht in der Busstatus-Ausgabe. > Wer weiß welche Macken das Board so hat, vom 644 und Netzwerk mal ganz > abgesehen, wobei es auch nur die Schmerzgrenze vom Benutzer zeigt ;-). Pfft :-P Ich weigere mich, das Senden von ein paar UART-Bytes in einen TCP-Socket mit einem ARM zu erschlagen ;-) Ethersex als AVR-Firmware ist wirklich empfehlenswert für solche Zwecke.
Danny Baumann schrieb: > Muss ich, wenn ich 0x0b als Antwort > gesendet habe, vor dem Senden des Break auf ein Echo des gesendeten > Bytes warten oder nicht? Die Aussagen im Thread sind da etwas > widersprüchlich... Also generell funktioniert das senden von den anderen Busteilnehmern (außer die 0x08) immer gleich. Jedes Byte wird mit dem schwachen Signalpegel gesendet und dann vom Busmaster (0x08) generell wiederholt. Man musss also immer auf das Echo warten. Denke nicht dass man es auswerten/kontrollieren muss. Das erledigt ja die Prüfsumme der EMS-Telegramme. Soweit ich mich erinnere sendet der Empfänger auf direkt an ihn adressierte Telegramme auch noch eine positive oder negative Bestätigung. Danny Baumann schrieb: > im Moment warte ich nicht, sehe aber Adresse 11 nicht > in der Busstatus-Ausgabe. Denke das wird das Problem sein. Allerdings erscheint bei mir nicht sofort der "PC" mit der Adresse 11 im Display, sondern erst nach der dritten Antwort auf das Polling (etwa 1Minute) Bei erscheinen der 11 in der RC30 kommt dann das Polling auch mehrmals in der Sekunde für die 0xb (11). Gruß Ingo
Ingo F. schrieb: > [Bus-Echo] Denke nicht dass man es auswerten/kontrollieren muss. Ich lege in meiner "Bitmanufaktur" (Soft-Uart) zwischen jedem gesendeten Zeichen - also auch vor dem Break - eine Pause von 30 Bitlängen (3 Byte) ein, funktioniert prächtig. //Niffko
Ingo F. schrieb: > Denke das wird das Problem sein. > Allerdings erscheint bei mir nicht sofort der "PC" mit der Adresse 11 im > Display, sondern erst nach der dritten Antwort auf das Polling (etwa > 1Minute) > Bei erscheinen der 11 in der RC30 kommt dann das Polling auch mehrmals > in der Sekunde für die 0xb (11). Es sieht bei mir so aus, als ob der MC10 meine Antwort mitbekommen hat (Polling ist mindestens 1x pro Sekunde), die RC30 allerdings nicht. Ich werde mal das Echo abwarten und dann mal sehen. Ich gehe mal davon aus, dass ich während des Sendens mein eigenes Echo auch auf der RX-Leitung sehen werde, d.h. während TX muss ich RX abschalten, richtig? Der MC10 wiederholt auch das gesendete Break, d.h. das muss ich auch abwarten, richtig? Danke.
Danny Baumann schrieb: > Es sieht bei mir so aus, als ob der MC10 meine Antwort mitbekommen hat > (Polling ist mindestens 1x pro Sekunde)... Ist das Polling denn vorher noch langsamer? 1x pro Sekunde ist eigentlich inaktives Polling, aktives Polling hat kürzere Intervalle. Das bezieht sich auf die EMS-Module. Könnte beim Service-Key anders sein - glaube ich aber nicht. > Ich gehe mal davon aus, dass ich während des Sendens mein eigenes Echo > auch auf der RX-Leitung sehen werde, d.h. während TX muss ich RX > abschalten, richtig? Wenn du die von mir gepostete Schaltung verwendest, dürfte dein eigenes TX den Komparator eigentlich nicht triggern. Wie das nach deiner Modifikation der Schaltung aussieht, weiß ich nicht. Sende doch einfach mal was und schau mit einem Oszi auf den Komparatorausgang. //Niffko
Niffko _ schrieb: > Danny Baumann schrieb: >> Es sieht bei mir so aus, als ob der MC10 meine Antwort mitbekommen hat >> (Polling ist mindestens 1x pro Sekunde)... > > Ist das Polling denn vorher noch langsamer? 1x pro Sekunde ist > eigentlich inaktives Polling, aktives Polling hat kürzere Intervalle. > Das bezieht sich auf die EMS-Module. Könnte beim Service-Key anders sein > - glaube ich aber nicht. Ok, dann war das ein Missverständnis meinerseits und der MC10 hat's auch nicht mitbekommen. >> Ich gehe mal davon aus, dass ich während des Sendens mein eigenes Echo >> auch auf der RX-Leitung sehen werde, d.h. während TX muss ich RX >> abschalten, richtig? > > Wenn du die von mir gepostete Schaltung verwendest, dürfte dein eigenes > TX den Komparator eigentlich nicht triggern. Wie das nach deiner > Modifikation der Schaltung aussieht, weiß ich nicht. > Sende doch einfach mal was und schau mit einem Oszi auf den > Komparatorausgang. Ich hab die Schaltung - nachdem ich jetzt weiß, dass es nicht daran lag - wieder auf deine 'Original'-Variante zurückgebaut. Mit dem Oszi tue ich mich dahingehend schwer, dass ich keinen sinnvollen Punkt zum Triggern habe, weil auf dem Bus ja ständig was los ist. Mal sehen, vielleicht geht's ja jetzt, wo ich den Code zum Warten eingebaut habe, ja einfach - ansonsten melde ich mich nochmal ;-) Danke für's Feedback auf alle Fälle schonmal.
Danny Baumann schrieb: > Muss ich, wenn ich 0x0b als Antwort > gesendet habe, vor dem Senden des Break auf ein Echo des gesendeten > Bytes warten oder nicht? Du musst warten, da es sonst zu Kollisionen kommt. Wenn der Bus vom Master getrieben wird (Echo), geht dein Sendestrom im rauschen unter. Grüße.
Danny Baumann schrieb: > Mal sehen, vielleicht geht's ja jetzt, wo ich den Code zum Warten > eingebaut habe ... Bad News ... es geht auch ohne Pausen - zumindest bei mir. Habe mich erinnert, dass wir das Thema "warten oder nicht warten" schon mal hatten. Ich hatte damals die Nicht-Warten-Fraktion gebildet, aber dann doch mit Fortschreiten meines Projektes sicherheitshalber eine Pause eingebaut. Interessehalber habe ich jetzt mal in meinem Code die Pausen herausgenommen ... und es funktioniert weiterhin alles wie gehabt. Wie es aussieht, scheint die Stromschnittstelle des Masters unabhängig vom Buspegel zu funktionieren - eine mögliche Erklärung: Beitrag "Re: Logamatic 2107 Schnittstelle" Ich werde das mal eine Weile so bei mir laufen lassen. //Niffko
Hallo Niffko, Niffko _ schrieb: > Ich werde das mal eine Weile so bei mir laufen lassen. Berichte dann mal von Deinen Ergebnissen... Beim Polling dürfte das vermutlich nicht so ein Problem sein. Weil man ja im Break sendet und dadurch das Sendesignal nicht unbedingt verfälscht wird. Aber Bei längeren Telegrammen dürfte das schon eher problematisch werden. Mag ja auch sein dass eine Weile lang läuft und dann irgendwann mal Probleme gibt und man dann nicht mehr dran denkt dass man die Pausen rausgenommen hat. Vielleicht ändert sich ja mal die Buslänge, es gibt eine neue Regelung, neue Software, neue Busteilnehmer, anderes Timing ... Die Temperatur oder Bauteilalterung/-toleranzen können ja auch irgendwann mal zuschlagen... Wenn es ja im Moment läuft muss es nicht heissen dass es immer läuft Drei Byte Bause wäre vielleicht auch etwas zu lang. Aber 1Byte und ein oder zwei Bits Aufschlag sollte schon reichen. Aber es dürfte ja kein Problem geben die Pause einzubauen. Oder ist Dein Controller so stark an der Auslastung dass da keine Zeit mehr für ist? Gruß Ingo
Sooo, jetzt geht's auch bei mir :-) Ich habe - die Schaltung wieder auf Niffko's Variante umgebaut - Warten auf Echo eingebaut - ganz wichtig: das Erzeugen des Breaks gefixt ;-) Ich hatte das Break im UDRE-Interrupt getriggert, wodurch es im letzten gesendeten Byte unterging und nur einen sehr kurzen Spike erzeugt hat. Jetzt triggere ich es im TXC-Interrupt, was offensichtlich (und logischerweise) besser funktioniert. Wenn's jemand interessiert: Mein Ethersex-Fork mit EMS-Support ist hier: https://github.com/maniac103/ethersex Vielen Dank nochmal an Niffko, Rudi und Ingo F. für den Input.
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
Mirko Rüther schrieb: > kurze Frage: wo unterscheiden sich die Schaltungen von IngoF > (http://www.mikrocontroller.net/attachment/97902/EMS.gif) > > und die von niffko > (http://www.mikrocontroller.net/attachment/95287/EMS_Interface.png)? Ingo's Schaltung ist vom genauen Spannungspegel auf dem EMS abhängig, Niffko's Schaltung nicht. Von der µC-Seite sollten beide identisch sein. > Würde mir gerne eine nachbauen und mit dem Code von Danny Baumann auf > einem Pollin Net I/0 betreiben. Du musst allerdings beachten, dass du, um meinen Code 1:1 verwenden zu können, einen Atmega644p brauchst (wegen der 2. UART). Das Ganze lässt sich auch auf USART0 umbauen (von der Softwareseite sogar recht einfach), allerdings ist beim Pollin-Board ja der MAX232 im Weg...
Danny Baumann schrieb: >> kurze Frage: wo unterscheiden sich die Schaltungen von IngoF >> (http://www.mikrocontroller.net/attachment/97902/EMS.gif) > Ingo's Schaltung ist vom genauen Spannungspegel auf dem EMS abhängig, > Niffko's Schaltung nicht. Von der µC-Seite sollten beide identisch sein. Also Meine Schaltung hatte ich selbst entwickelt. Niffko hat dann die Schaltung von Buderus herausbekommen. Bei meiner Schaltung habe ich auch feststellen müssen dass sie beim Senden das Empfangsignal beinflusst. Das hat sich aber nicht in Fehlern bemerkbar gemacht. Ich habe jetzt auf meinem EMS-Gateway auch die Niffko/Buderus-Schaltung genommen. Kann das auch nur empfehlen. Habe das Senden aber bisher noch nicht mit der neuen Schaltung testen können. Denke damit wird es aber nicht diese Probleme geben Gruß Ingo
Hi, ich habe Niffko's Schaltung aufgebaut, mit Optokopplern galvanisch getrennt, dann auf 3,3V Pegel runter und auf einen FTDI UART USB Chip. Das funktioniert irgendwie nicht, auch nicht das Terminalprogramm einfach mitlaufen lassen, da kommt nichts raus und die Eco-Soft verbindet sich auch nicht. Habe ich bei der ganzen Sache noch irgendwas übersehen? Gruss Norbert
Norbert Schnitzler schrieb: > Das funktioniert irgendwie nicht, auch nicht das Terminalprogramm > einfach mitlaufen lassen, da kommt nichts raus und die Eco-Soft > verbindet sich auch nicht. Liegt wohl irgendwie am Wetter. Für die ECO-Soft brauchst du einen Dongle. Grüße.
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
Hallo Norbert, Die Schaltung ist eigentlich nur ein "Pegelwandler" mit USB-Anschluss. Wenn alles richtig aufgebaut ist sollten massenhaft Daten rauskommen wenn man ein Terminalprogramm anschließt. Fehlerquellen gibt es genug... Die schaltung selber kann nicht funktionieren... Die Optokoppler könnten die Probleme sein.... Der USB-Chip könnte natürlich auch irgendwelche Probleme haben. Den FTDI-Chip (FT245RL) kann man die Ausgänge mit der FTDI-Software programmieren dass die Ausgänge einen höhren Strom liefern um z.B. Optokoppler mit Strom zu versorgen.. Da hilft wohl nur einen Schaltungsteil nach dem anderen zu prüfen... Das die Eco-Soft nicht funktioniert ist kein Wunder. Erstens bekommst Du noch niemals auf dem Terminalprogramm Daten. Und zweitens benötigt die EcoSoft noch zusätzlich einen "Protokollkonverter" Weil die Daten zur EcoSoft anders übertragen werden. Desweiteren gibt es noch Probleme das auf dem Bus jedes Telegramm mit einem Break beendet wird. Der PC ist zu langsam um dieses Break auszuwerten. Dazu müsste er jedes Zeichen einzeln empfangen können und ist dazu einfach zu langsam. Dann gibt es noch das Problem dass Du zwar alle möglichen Daten auf dem PC mit dem Terminalprogramm empfangen kannst, aber das Break nur als normale "0" übertragen wirde. Der FT245RL hat keine Möglichkeit das Break zu senden oder zu empfangen. Denke der FT232 wird da das selbe Problem haben. Gruß Ingo
Hallo, Herbert schrieb: > Ist zwar etwas aus dem Zusammenhang gehört aber in diesen Thread: > Die Schnitstelle der Logamatic 2107 mit der Fernbedienung BFU: > http://wiki.neo-soft.org/index.php/Heizungsschnittstelle/BFU danke für die Info. Ein paar Bilder wären nicht schlecht, falls du darauf einen Einfluss hast ;-). Grüße.
Rudi schrieb: > Hallo, > > Herbert schrieb: >> Ist zwar etwas aus dem Zusammenhang gehört aber in diesen Thread: >> Die Schnitstelle der Logamatic 2107 mit der Fernbedienung BFU: >> http://wiki.neo-soft.org/index.php/Heizungsschnittstelle/BFU > > danke für die Info. Ein paar Bilder wären nicht schlecht, falls du > darauf einen Einfluss hast ;-). > > Grüße. Ich frag mal ganz blöd: Welche Bilder meinst Du ?
Hallo Ingo, danke für die ausführliche Antwort, welches ist denn, deiner Meinung nach, die beste Möglichkeit auf die aktuellen Daten und evtl. auf Historiendaten per Heizung zuzugreifen. Dazu wurde hier zwar einiges geschrieben, aber leider ist es ja etwas unübersichtlich. Gruss Norbert
Hallo Norbert, das Problem ist dass ein PC nicht jedes Zeichen einzeln annimmt. Die Bytes werden in einen Zwischenbuffer abgelegt und dann wenn der PC mal Zeit hat der Buffer geleert. Das Break löst einen Frame-Error aus. Der PC kann also nur sehen dass irgend ein Zeichen von den ganzen Zeichen das Break war. Kann aber nicht feststellen welches Zeichen es war. Es muss also ein Mikrocontroller sein der die Daten annimmt und die Daten zum PC schickt. Wenn noch geschrieben werden soll muss auch das Polling am Bus beantwortet werden. Keine Ahnung ob es mit einem Linux-PC klappen könnte. Aber vermutlich sind PCs generell dafür zu langsam. Gruß Ingo
Hallo Ingo, meine Frage war in die Richtung gemünzt, ob hier einer der vielen Autoren eine 'einfache' Hardwarelösung genutzt hat, bei der der Code zugänglich ist, so dass man diese nur nachbauen muss und direkt ein funktionierendes System hat, ohne selber alles zu entwickeln. Ich würde mich zwar gerne tiefer in die Materie einarbeiten, aber mir geht es im Moment nur darum, möglichst schnell ans Ziel zu kommen und Zugriff auf die Daten zu bekommen. Gruss Norbert
Norbert Schnitzler schrieb: > Autoren eine 'einfache' Hardwarelösung genutzt hat Na gut dann habe ich zumindest schon mal aufgeklärt ;o) Fragt sich nur wie "Einfach" Du meinst. Denke die Schaltung ohne Microcontroller nehmen wird wohl nicht aus den genannten Gründen gehen. Niffko hat ja den kompletten Schaltplan schon gepostet. Also mit µC nachbauen und dann sollte es laufen. Oder hast Du die Schaltung mit µC nachgebaut und ich hatte das nicht so ganz verstanden. Einfach mal Niffko fragen ob er seinen Quelltext oder das HEX-File rausrückt. Meinen Schaltplan hatte ich ja schon gepostet ( Beitrag "Re: Buderus EMS-"Gateway" mit PIC18F / Sammelbestellung" ) Aber der wird Dir dann wohl zu komplex sein. Könnte man aber bis auf den FTDI-Chip auf mit nicht-SMD Bauteilen nachbauen. Das HEX-File kannst Du natürlich gerne bekommen... Gruß Ingo
Hallo Ingo, bis jetzt hatte ich nur die Sende-/Empfangsstufe nachgebaut, ich schau morgen mal auf der Arbeit, ob ich da einen passenden Pic finde, dann wäre es ja kurz und schmerzlos auszubauen. Platinen hast du keine mehr oder? Wie/In welchem Format schiebst du die Daten zur seriellen Schnittstelle raus? welches Display kann man Anschließen (4x20Zeichen)? Gruss Norbert
Norbert Schnitzler schrieb: > ob ich da einen passenden Pic finde Also wenn dann muss es schon der 18F4580 oder 4480 sein falls Du mein Hex File benutzen möchtest. Der FT245RL muss natürlich auch genauso angeschlossen werden und die Analoge-Mode-Auswahl mit dem Dipschalter. Und natürlich Die Sende-/Empfangsstufe, die ja noch nicht so ganz funktioniert. Das Display ist im Moment noch absolut egal. Habe im Moment ein 4X20 angeschlossen. Aber im Moment wird es noch nicht benutzt. Sind nur ein paar Ausgaben zum testen für die Kommunikation mit dem USB-Chip. Ausgabe ist in zwei Versionen verfügbar: Hex: 0xAA 0x55 <EMS-Telegramm> 0x00 <Telegrammlänge> 0xAA 0x55 oder als Text das Telegramm in HEX mit Leerzeichen zum trennen und <CR&LF> am Telegrammende. Polling wird nicht übertragen. Soll aber zum debuggen bald möglich sein. Gruß Ingo
Wenn's nicht unbedingt ein PIC sein muss, habe ich weiter oben schon mal einen Link zu meinem Code für den Atmega644p auch dem Pollin-Net-IO-Board gepostet...
Nabend! Werde in Kürze mal den Code für eine Read-Only-Minimalversion posten - muss ihn noch ein wenig aufräumen und noch mal testen ;) Hardware siehe: Beitrag "Re: Logamatic 2107 Schnittstelle" //Niffko
Guten morgen, Also ich habe einen Atmega 32 hier und PIC18F4620, würde dein Hex direkt auf diesen PIC passen oder kann man den in MPLAB schnell passend kompilieren, Ingo? Wenn nicht würde ich umkompilieren mit dem Atmel versuchen. Gruss Norbert
Norbert Schnitzler schrieb: > Guten morgen, > > Also ich habe einen Atmega 32 hier und PIC18F4620, würde dein Hex direkt > auf diesen PIC passen oder kann man den in MPLAB schnell passend > kompilieren, Ingo? > Wenn nicht würde ich umkompilieren mit dem Atmel versuchen. > > Gruss > Norbert Hallo Norbert, also generell kann ich das nicht garantieren. Sieht aber ganz gut aus. Du musst allerdings alles so sbeschalten wie in meinem Schaltplan angegeben. Der CAN-Eingang (RB2) muss dann z.B. mit 10KOhm auf irgendeinen Pegel gelegt werden. Beim Mikrocontroller muss LVP in den Bits deaktiviert werden oder der Pin (RB5??) muss auch mit 10kohm auf Low gezogen werden (nicht getestet, bei mir deaktiviert) Wichtig ist die analoge beschaltung beim Einschalten und reset. Etwa 0V = AN1310 Bootloader >0V <0,2 Volt RAW-Daten mit 0xaa 0x55 >0,2V HEX als Text mit CR&LF Und es muss der FT245 sein. Der Ft232 funktioniert nicht mit meinem HEX-File (zweiter UART notwendig) Kann allerdings nicht versprechen das es noch funktioniert wenn ich den CAN-interupt bei späteren Versionen aktiviere. Vermutlich sollte das aber gehen. Das HEX-File kann ich aber vermutlich erst morgen posten. Gruß Ingo
IngoF schrieb: > Das HEX-File kann ich aber vermutlich erst morgen posten. Hab es leider nicht schneller geschafft.. LED2 leuchtet wenn der PC über USB verbunden ist. LED1 leuchtet wenn der Buffer des FT245 voll ist und sollte also bei angeschlossenem PC nicht wirklich oft lange leuchten. Im Bereich bis 0x3ff ist der modifizierte AN1310-Bootloader Ab 0x400 ist da eigentliche Programm. Bisher ist nur das weiterleiten vom EMS-Bus zum PC möglich. Das Polling auf dem EMS-Bus wird nicht beantwortet. Gruß Ingo
Angehängte Dateien:
-
EMS_Reader_V1.png
16 KB
Nabend! Anhängend Schaltplan und Hex-File für einen EMS-Reader. Funktion: Das Bussignal wird über AC-Kopplung auf den internen Komparator eines ATtiny2313 gegeben. Das Komparatorsignal triggert einen interruptgesteuerten Soft-UART mit 100 Byte FIFO. Die Ausgabe läuft über den Hard-UART des Tiny. Schnittstellenperipherie dann je nach Gusto als FT232, MAX232, Optokoppler etc.. Optionen: -Ausgabe ASCII Hex + <CR+LF> -Ausgabe Raw ( Format: <AA><55><Frame-Länge><Frame-Data> ) -Ausgabe mit Polling -Ausgabe ohne Polling //Niffko
Mal eine Frage an die 'Sendenden': Reagiert die RC3x bei euch zuverlässig auf Anfragen? Ich versuche im Moment den Fehlerspeicher auszulesen und sende folgendes: 0x0b 0x90 0x12 0x00 0x0c <crc> (lese 1. Eintrag mit 12 Bytes) ... warte auf Antwort, die kommt in 100% der Fälle ... 0x0b 0x90 0x12 0x0c 0x0c <crc> (lese 2. Eintrag) ... die kommt eigentlich auch immer ... 0x0b 0x90 0x12 0x18 0x0c <crc> (lese 3. Eintrag) ... ab hier wird's unzuverlässig, oft bekomme ich da keine Antwort 0x0b 0x90 0x12 0x24 0x0c <crc> (lese 4. Eintrag) ... dito ... Seht ihr so was bei euch auch (hieße für mich: Retry einbauen) oder eher nicht (da müsste ich noch mal in meinen Ethersex-Code schauen)? Kann einer von euch mal versuchen, das zu reproduzieren? Danke.
Hi Danny, eine Frage vorne weg: Lässt du zwischen den aufeinander folgenden Abfragen Pausen oder prüfst du ob der RC3X geliefert hat? Ich habe deine Abfrage mal in mein Anwendung hinein gehackt. Aus Aufwandsgründen allerdings nur mit Pausen zwischen den Einzelabfragen. Dein Problem konnte ich nachvollziehen. Kurz gesagt - es ist ein Zeitproblem. Es sieht so aus, als wenn der RC3X, 4 kurz aufeinander folgende Abfragen á 12 Byte nicht so schnell gebacken kriegt. Was 100% immer funktioniert hat waren 2 Abfragen á 24 Byte - die müsstest du dann halt noch auseinander pflücken. Andere Alternative: Jeden 12 Byte Block auf eine neue Polling-Anfrage verteilen. //Niffko
> eine Frage vorne weg: Lässt du zwischen den aufeinander folgenden > Abfragen Pausen oder prüfst du ob der RC3X geliefert hat? Letzteres. Ich schicke jeweils eine Abfrage los und warte auf Antwort. Mein Ethersex-Code macht die TCP-Verbindung eh so lange dicht, bis er die Abfrage abgesetzt hat. > Ich habe deine Abfrage mal in mein Anwendung hinein gehackt. Aus > Aufwandsgründen allerdings nur mit Pausen zwischen den Einzelabfragen. > Dein Problem konnte ich nachvollziehen. Kurz gesagt - es ist ein > Zeitproblem. Es sieht so aus, als wenn der RC3X, 4 kurz aufeinander > folgende Abfragen á 12 Byte nicht so schnell gebacken kriegt. Was 100% > immer funktioniert hat waren 2 Abfragen á 24 Byte - die müsstest du dann > halt noch auseinander pflücken. Andere Alternative: Jeden 12 Byte Block > auf eine neue Polling-Anfrage verteilen. Das (1 Abfrage pro Polling) hatte ich halt schon getan. Final will ich auch nur 2 Abfragen abschicken (schon aus Performance-Gründen, da ja ordentlich Latenz reinkommt, da ich ja jedesmal erst mal auf's Polling warten muss), allerdings will ich das Problem erst mal verstehen - schließlich könnte es ja sein, dass meine Anfrage (aus welchen Gründen auch immer) verlorengegangen ist. Wenn das aber normal wäre, dass der RC3x (in meinem Fall: RC30) manchmal Aussetzer hat, müsste ich mir ja keine größeren Sorgen machen. Allerdings frag ich mich grad, ob es dann nicht besser wäre, alle Anfragen/Kommandos an 0x90/0x88 zu senden, damit man wenigstens eine Rückmeldung hat, ob die Anfrage angekommen ist. Der interne Puffer der RC3x scheint ohnehin klein zu sein, wenn ich '0x0b 0x90 0x12 0x00 0xff' sende, bekomme ich auch nur 25 oder 26 Byte Nutzdaten zurück.
Danny Baumann schrieb: > Ich schicke jeweils eine Abfrage los und warte auf Antwort. Um bei ausbleibender Antwort eine Hängepartie zu vermeiden, müsstest du ja dann auch einen Timeout eingebaut haben - hast du? Nur mal so als Hausnummer - ich musste die Pause zwischen der Einzelabfrage(12 Byte, letzter Block) und dem abschließenden <0B> auf 200ms setzen um zuverlässig eine Antwort zu bekommen. Wobei (bei mir) aber auch schon ca. 20ms vergangen sind, bis der Master die Anfrage vollständig auf den Bus geechot hat. Danny Baumann schrieb: > ... schließlich könnte es ja sein, dass meine Anfrage (aus welchen Gründen > auch immer) verlorengegangen ist. Glaube ich nicht. Ich hatte beim Testen zum Senden und Empfangen jeweils separate Hardware und dürfte somit sicher alle Telegramme mitgeschnitten haben. Das Anfragetelegramm wurde immer korrekt wiedergegeben, es kam aber trotzdem sporadisch keine Antwort vom RC35. Danny Baumann schrieb: > ... alle Anfragen/Kommandos an 0x90/0x88 zu senden, > damit man wenigstens eine Rückmeldung hat, ob die Anfrage angekommen > ist. öhmm ... hier kann ich dir irgendwie nicht ganz folgen. //Niffko
Niffko _ schrieb: > Danny Baumann schrieb: >> Ich schicke jeweils eine Abfrage los und warte auf Antwort. > > Um bei ausbleibender Antwort eine Hängepartie zu vermeiden, müsstest du > ja dann auch einen Timeout eingebaut haben - hast du? Nur mal so als Nein, noch nicht, kann ich aber einfach tun. > Hausnummer - ich musste die Pause zwischen der Einzelabfrage(12 Byte, > letzter Block) und dem abschließenden <0B> auf 200ms setzen um > zuverlässig eine Antwort zu bekommen. Wobei (bei mir) aber auch schon > ca. 20ms vergangen sind, bis der Master die Anfrage vollständig auf den > Bus geechot hat. Das heißt, du schließt jedes Senden mit einem leeren Telegramm ab? Ich hatte (hier im Thread) gelesen, dass dss nicht nötig sei. > > Danny Baumann schrieb: >> ... schließlich könnte es ja sein, dass meine Anfrage (aus welchen Gründen >> auch immer) verlorengegangen ist. > > Glaube ich nicht. Ich hatte beim Testen zum Senden und Empfangen jeweils > separate Hardware und dürfte somit sicher alle Telegramme mitgeschnitten > haben. Das Anfragetelegramm wurde immer korrekt wiedergegeben, es kam > aber trotzdem sporadisch keine Antwort vom RC35. > Ok, das beruhigt mich...das heißt also, dass das Verhalten, das ich sehe, 'normal' ist. > Danny Baumann schrieb: >> ... alle Anfragen/Kommandos an 0x90/0x88 zu senden, >> damit man wenigstens eine Rückmeldung hat, ob die Anfrage angekommen >> ist. > > öhmm ... hier kann ich dir irgendwie nicht ganz folgen. Wenn man auf die Empfänger-Adresse 0x80 drauf-odert (d.h. 0x08 -> 0x88 und 0x10 -> 0x90) gibt man ja an, dass man eine Antwort erwartet. Wenn man die bekommt, kann man sich sicher sein, dass das Kommando angekommen (und verstanden) ist. > > > > > //Niffko
Nabend, ich habe mal ein frage zum EMS-collector. Habe die Quellen auf einem std. Debian 6 mit den boost & mysql libs übersetzt root@debian6:~/ems-collector/collector# make g++ -Wall -c -O2 -I/usr/include/mysql -I../framer -MM main.cpp SerialHandler.cpp Message.cpp Da tabase.cpp Options.cpp PidFile.cpp > .depend g++ -Wall -c -O2 -I/usr/include/mysql -I../framer main.cpp g++ -Wall -c -O2 -I/usr/include/mysql -I../framer SerialHandler.cpp g++ -Wall -c -O2 -I/usr/include/mysql -I../framer Message.cpp g++ -Wall -c -O2 -I/usr/include/mysql -I../framer Database.cpp g++ -Wall -c -O2 -I/usr/include/mysql -I../framer Options.cpp g++ -Wall -c -O2 -I/usr/include/mysql -I../framer PidFile.cpp g++ -lpthread -lboost_system -lboost_thread-mt -lboost_program_options -lmysqlpp -o collectord main.o SerialHandler.o Message.o Database.o Options.o PidFile.o Wenn ich das ganze starte bekomme ich auch keine Fehlermeldung und die DB ems_data wird auch schön angelegt. ./collectord -u root -p passwd -d all=/tmp/ems.log /dev/ttyUSB0 Die Datenbank füllt sich nur leider nicht. Im Logfile finden sich auch nur die Daten vom SERIAL(port). ... SERIAL: Got bytes 00 0x77 00 0x17 0xaa 0x55 SERIAL: Got bytes 0xaa 0x55 0x8 00 0x18 00 0x2b 0x1 0xb1 0x64 00 0x1 0x1 0x20 0x60 0x80 00 0x2 0x7 0x1 0xb1 00 00 0xf 0x30 0x59 00 0xcc 00 00 00 0x6f 00 0x1f 0xaa 0x55 SERIAL: Got bytes 0xaa 0x55 0x10 0x21 0xac 00 0x1d 0x64 0x3 0xa5 00 0x9 0xaa 0x55 ... Wie kann ich hier weiter debuggen woran könnte es scheitern? Zweite Frage wir kann ich eine Binary erstellen die alle Libs direkt enthält? Auf meinem Server läuft noch Debian Lenny und da will die boost lib nicht :-( Danke!
Kay F. schrieb: > SERIAL: Got bytes 00 0x77 00 0x17 0xaa 0x55 > SERIAL: Got bytes 0xaa 0x55 0x8 00 0x18 00 0x2b 0x1 0xb1 0x64 00 0x1 0x1 > 0x20 0x60 0x80 00 0x2 0x7 0x1 0xb1 00 00 0xf 0x30 0x59 00 0xcc 00 00 00 > 0x6f 00 0x1f 0xaa 0x55 > SERIAL: Got bytes 0xaa 0x55 0x10 0x21 0xac 00 0x1d 0x64 0x3 0xa5 00 0x9 > 0xaa 0x55 Alles zwischen 0xaa 0x55 und <len> 0xaa 0x55 sind die Heizungsdaten. Die "<len>" bezieht sich auf die EMS-Daten, also sind es insgesamt LEN+5 Bytes. > > Wie kann ich hier weiter debuggen woran könnte es scheitern? > Zweite Frage wir kann ich eine Binary erstellen die alle Libs direkt > enthält? Auf meinem Server läuft noch Debian Lenny und da will die boost > lib nicht :-( Versuch mal den Schalter -static für den gcc/g++. Mit ldd <appl> kannst du sehen welche Lib noch dynamisch gelinkt ist. Grüße.
Danny Baumann schrieb: > Das heißt, du schließt jedes Senden mit einem leeren Telegramm ab? Ja klar ... genau wie alle anderen Busteilnehmer auch. Damit signalisiert man dem Master: "habe fertig!". > Ich hatte (hier im Thread) gelesen, dass dss nicht nötig sei. Naja ... der Timeout wird's schon richten. Danny Baumann schrieb: > Allerdings frag ich mich grad, ob es dann > nicht besser wäre, alle Anfragen/Kommandos an 0x90/0x88 zu senden, Danny Baumann schrieb: > Wenn man auf die Empfänger-Adresse 0x80 drauf-odert (d.h. 0x08 -> 0x88 > und 0x10 -> 0x90) gibt man ja an, dass man eine Antwort erwartet. Ja, das ist klar. Ich weiß nur nicht, wo du hier eine Wahlmöglichkeit siehst. Wenn man von einem Teilnehmer Daten haben möchte, kommt die 0x80 mit drauf. Handelt es sich um eine Anweisung/Parametrierung, dann nicht. Im letzten Fall bekommt man übrigens auch Rückmeldung, nämlich 0x01 für "ok" und 0x04 für "Fehler". //Niffko
Hi, > Die Datenbank füllt sich nur leider nicht. Im Logfile finden sich auch > nur die Daten vom SERIAL(port). > > ... > SERIAL: Got bytes 00 0x77 00 0x17 0xaa 0x55 > SERIAL: Got bytes 0xaa 0x55 0x8 00 0x18 00 0x2b 0x1 0xb1 0x64 00 0x1 0x1 > 0x20 0x60 0x80 00 0x2 0x7 0x1 0xb1 00 00 0xf 0x30 0x59 00 0xcc 00 00 00 > 0x6f 00 0x1f 0xaa 0x55 > SERIAL: Got bytes 0xaa 0x55 0x10 0x21 0xac 00 0x1d 0x64 0x3 0xa5 00 0x9 > 0xaa 0x55 > ... > > Wie kann ich hier weiter debuggen woran könnte es scheitern? Das Format sieht aber nicht nach meinem Atmega-Code aus. Es sieht aus wie 0xaa 0x55 <ems data> <ems checksum> 0xaa 0x55 Der Collector erwartet aber 0xaa 0x55 <frametype> <length> <ems data> <running xor checksum> Siehe das Unterverzeichnis framer/. Du kannst jetzt entweder deinen µC entsprechend umstellen (wenn's ein Atmega ist, hab ich den Code ja mitgeliefert) oder SerialHandler.cpp umbauen. Out-of-the-Box geht das so nicht.
>> Das heißt, du schließt jedes Senden mit einem leeren Telegramm ab? > > Ja klar ... genau wie alle anderen Busteilnehmer auch. Damit > signalisiert man dem Master: "habe fertig!". > >> Ich hatte (hier im Thread) gelesen, dass dss nicht nötig sei. > > Naja ... der Timeout wird's schon richten. Ok, dann jetzt mal Butter bei die Fische, um das mal aufzulösen :) Wenn ich nix zu senden habe, passiert ja das hier: <0x8b><brk> <0x0b><brk> (letzteres kommt von mir) Wenn ich etwas zu sagen habe, muss also folgendes passieren? <0x8b><brk> <0x0b><data_1>...<data_n><brk> <0x0b><brk> Wenn dem so ist, bekomme ich dann auch ein Echo für das Break, d.h. kann ich auf ein empfangenes Byte 0x00 warten? >> Allerdings frag ich mich grad, ob es dann >> nicht besser wäre, alle Anfragen/Kommandos an 0x90/0x88 zu senden, > >> Wenn man auf die Empfänger-Adresse 0x80 drauf-odert (d.h. 0x08 -> 0x88 >> und 0x10 -> 0x90) gibt man ja an, dass man eine Antwort erwartet. > > Ja, das ist klar. Ich weiß nur nicht, wo du hier eine Wahlmöglichkeit > siehst. Wenn man von einem Teilnehmer Daten haben möchte, kommt die 0x80 > mit drauf. Handelt es sich um eine Anweisung/Parametrierung, dann nicht. > Im letzten Fall bekommt man übrigens auch Rückmeldung, nämlich 0x01 für > "ok" und 0x04 für "Fehler". Das ist interessant, genau diese Rückmeldung scheine ich nicht zu bekommen. Ich sende z.B. zum Ändern des Warmwasser-Modus (aus/an/auto) 0x0b 0x10 0x37 0x02 0x02 <crc> <brk> Ich sollte also eine Antwort bekommen, die so aussieht? 0x10 0x0b 0x1 <crc> <brk> Genau das scheint nicht zu passieren. Der Modus wird aber korrekt geändert, das sehe ich ja an der RC30. Wenn ich die 0x10 in der Anfrage durch 0x90 ersetze, bekomme ich eine Antwort, die sich allerdings scheinbar eher auf die gesetzten Daten bezieht, als dass sie 0x1/0x4 zurückliefern würde.
Hallo, danke für die Antworten. Jetzt verstehe ich das Konstrukt ein wenig besser. Ich nutze das EMS-Gateway von Ingo (PIC), somit kann ich den Framer nicht verwenden. Wenn es okay ist, würde ich den Quelltext von Danny mißbrauchen und umbauen. Wenn ich das gerade auf die schnelle richtig gesehen habe, sind die Formate ja nicht so unterschiedlich: 0xaa 0x55 <ems data> <length> 0xaa 0x55 0xaa 0x55 <frametype> <length> <ems data> <running xor checksum> <frametype> ist immer 0 (FRAME_TYPE_DATA) da der PIC keine Statistik hat. Also muss ich nur die SerialHandler::readComplete(..) verstehen und anpassen..... Gruß Kay
> danke für die Antworten. Jetzt verstehe ich das Konstrukt ein wenig > besser. Ich nutze das EMS-Gateway von Ingo (PIC), somit kann ich den > Framer nicht verwenden. Wenn es okay ist, würde ich den Quelltext von > Danny mißbrauchen und umbauen. Wenn ich das gerade auf die schnelle Das ist ok, ist ja Open Source - vergiss nur nicht, deine Änderungen wieder zur Verfügung zu stellen ;) > richtig gesehen habe, sind die Formate ja nicht so unterschiedlich: > > 0xaa 0x55 <ems data> <length> 0xaa 0x55 Ja, wobei Ingo die EMS-Prüfsumme über RS232 weiterreicht, was ich nicht tue (ich prüfe die im Atmel). Das Break scheint auch enthalten zu sein, d.h. das Format wäre 0xaa 0x55 <ems data> <ems checksum> <0x00=brk> <length between markers> 0xaa 0x55 > 0xaa 0x55 <frametype> <length> <ems data> <running xor checksum> > > <frametype> ist immer 0 (FRAME_TYPE_DATA) da der PIC keine Statistik > hat. Hmm? Frametype gibt's nur in meinem Format, was hat das mit dem PIC zu tun? > Also muss ich nur die SerialHandler::readComplete(..) verstehen und > anpassen..... Richtig, sollte aber nicht übermäßig schwierig sein :)
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
>> Ok, dann jetzt mal Butter bei die Fische ... > > Aber gerne ... Danke :) > Abfrage: >
1 | > RX: <0x8b> <brk> |
2 | > TX: <0x0b> <0x88> <content> <crc> <brk> |
3 | > RX: <0x08> <0x0b> <content> <crc> <brk> |
4 | > TX: <0x0b> <brk> |
5 | > |
Ok, verstehe. Das sollte sich ja recht leicht einbauen lassen. > Anweisung: >
1 | > RX: <0x8b> <brk> |
2 | > TX: <0x0b> <0x08> <content> <crc> <brk> |
3 | > RX: <0x01> <brk> |
4 | > TX: <0x0b> <brk> |
5 | > |
> > > Ich schätze mal, die 0x01 versackt bei dir im Polling - oder? In der Tat. Alle Nachrichten mit nur 1 Byte sehe ich als Polling an. Sieht so aus, als ob ich 0x01 und 0x04 speziell behandeln muss. Vom Protokoll her sieht das aber echt bekloppt aus - wenn man eine Status-Antwort gibt, warum schickt man die dann nicht an den Absender der Anweisung? seufz Naja, jammern nützt nix, ändern können wir es eh nicht, also muss ich das wohl einbauen ;) Danke aber auf alle Fälle für die Infos. Weißt du, ob das Break vom MC10 'geechot' wird?
Danny Baumann schrieb: > Weißt du, ob das Break vom MC10 'geechot' wird? Überleg' mal ... alle Telegramme die du auf dem Bus siehst, sind - mit Ausnahme derer vom Master selbst - alles Echos. Und alle haben ein Break ... also?! ;) //Niffko
Niffko _ schrieb: > Danny Baumann schrieb: >> Weißt du, ob das Break vom MC10 'geechot' wird? > > Überleg' mal ... alle Telegramme die du auf dem Bus siehst, sind - mit > Ausnahme derer vom Master selbst - alles Echos. Und alle haben ein > Break ... also?! ;) Hast ja recht, da hätte man mit etwas nachdenken drauf kommen können :) Ich werd jetzt mal meinen Atmel-Code umbauen...
Nabend ;) Ich habe jetzt noch mal den ganzen Thread durchgesehen, aber nix gefunden. Habt ihr mittlerweile herausgefunden wie sich die Außentemperatur im Minusbereich berechnen lässt? Gruß Jens
> Ich habe jetzt noch mal den ganzen Thread durchgesehen, aber nix > gefunden. Habt ihr mittlerweile herausgefunden wie sich die > Außentemperatur im Minusbereich berechnen lässt? Ja klar ;) Direkt aus meinem Code (von hier: Beitrag "Re: Logamatic 2107 Schnittstelle" - Message.cpp):
1 | /* treat values with highest bit set as negative |
2 | * e.g. size = 2, value = 0xfffe -> real value -2 |
3 | */ |
4 | if (m_buffer[offset] & 0x80) {
|
5 | value = value - (1 << (size * 8)); |
6 | } |
D.h.: gelesen 0xffdd -> Wert = 0xffdd - (1 << 16) = 0xffdd - 0x10000 = 65501 - 65536 = -35 Wenn ich mich recht entsinne, ist die Außentemperatur als 16-bit-Wert mit einer Nachkommastelle gespeichert, d.h. im Beispielfall wären das -3.5°C.
Jens H. schrieb: > ... Außentemperatur im Minusbereich berechnen ... Das ist ein ganz normaler signed Integer16. Ich stopfe meine empfangenen Bytes z.B. alle per Byte-Pointer in die entsprechenden Variablen. Pseudocode:
1 | uint8_t *pointer; |
2 | int16_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
Ok, danke für den Hinweis zu den Minustemperaturen, aber was is denn die "normale" und was die "gedämpfte" Außentemp? Das geht scheinbar ein wenig unter .. zumindest in den Listen die ich hier im Thread gefunden habe. Auf diverse Codeschnipsle hatte ich jetzt nicht so geachtet, da ich vor habe das mit PHP zu lösen. Gruß Jens
Jens H. schrieb: > Ok, danke für den Hinweis zu den Minustemperaturen, aber was is denn die > "normale" und was die "gedämpfte" Außentemp? Das geht scheinbar ein > wenig unter .. zumindest in den Listen die ich hier im Thread gefunden > habe. Die gedämpfte AT wird zur Regelung benutzt und durch mehrere Parameter berechnet (AT/Gebäudeart etc.). Grüße.
Die gedämpfte AT vollzieht Änderungen der realen AT mit einer gewissen zeitlichen Verzögerung nach. Hiermit soll die thermische Trägheit des Baukörpers berücksichtigt werden. Die Intensität der Dämfung ist abhängig von der eingestellten Gebäudeart. Im Gegensatz zum RC30 ist die Dämpfung mit dem RC35 auch komplett abschaltbar. Wie Rudi schon schrieb, wird mit der gedämpften AT über die Heizkennlinie die Vorlaufsolltemperatur berechnet. Für die So/Wi-Umschaltung ist sie übrigens auch verantwortlich. //Niffko
Hallo, ich habe irgendwie Probleme den Quellcode von Danny zuverstehen, was an meiner fehlenden Erfahrung im Bereich c++ liegen kann ;-) Ich habe versucht die SerialHandler::readComplete() Funktion anzupassen, was ich eigentlich als nicht so schwierig erachtet habe. Im Debug Mode erkennt man das die Funktion mit dem richtig erkannten Anfang & Ende aufgerufen wird: SERIAL: Got bytes 0xaa 0x55 0x8 00 0x34 00 0x32 0x1 0xfd 0x1 0xfd 0x21 00 0x5 0x3 00 00 0x8b 0xef 00 0x8 0xfc 00 0xe 00 0x17 0xaa 0x55 Die EMS Daten stehen ja in m_recvBuffer die ich jetzt von 2 bis (bytesTransferred -3) in DataMessage kopieren muss und gut ist. Irgenwie haut das aber nicht hin und ich bekomme segvaults und andere unschöne sachen :-( Ich habe die Funktion mal angehängt. Ist das mit den einfachen nullen so okay, oder was paßt nicht? Danke und Gruß Kay
Hi, > ich habe irgendwie Probleme den Quellcode von Danny zuverstehen, was an > meiner fehlenden Erfahrung im Bereich c++ liegen kann ;-) > Ich habe versucht die SerialHandler::readComplete() Funktion anzupassen, > was ich eigentlich als nicht so schwierig erachtet habe. Im Debug Mode > erkennt man das die Funktion mit dem richtig erkannten Anfang & Ende > aufgerufen wird: > SERIAL: Got bytes 0xaa 0x55 0x8 00 0x34 00 0x32 0x1 0xfd 0x1 0xfd 0x21 > 00 0x5 0x3 00 00 0x8b 0xef 00 0x8 0xfc 00 0xe 00 0x17 0xaa 0x55 Das ist nicht 'richtig erkannt', dass ist Glück, dass mit 1x lesen genau ein Paket zurückkam. Es hätte auch sein können, dass 2 Pakete mit einem mal gelesen werden, oder dass ein Paket in 2 Teilen ankommt. Aus diesem Grund hatte ich ja die State Machine gebaut, die jedes Byte einzeln anschaut... > Die EMS Daten stehen ja in m_recvBuffer die ich jetzt von 2 bis > (bytesTransferred -3) in DataMessage kopieren muss und gut ist. > Irgenwie haut das aber nicht hin und ich bekomme segvaults und andere > unschöne sachen :-( > > Ich habe die Funktion mal angehängt. Ist das mit den einfachen nullen so > okay, oder was paßt nicht? Bei mir kommt <Start-Marker> <Länge> <Daten>, bei Ingo <Start-Marker> <Daten> <Länge> <End-Marker>. m_recvBuffer[2] ist bei dir also nicht die Länge, sondern das erste Nutzbyte. Du allokierst also 8 Byte in der Message und füllst dann 23 oder 24 Bytes rein ... nicht gut. Es hätte funktioniert (d.h. wäre nicht gecrasht), wenn die Nachricht vom Mischer gekommen wäre ;) Du musst also etwas umbauen (Nachricht in std::vector<uint8_t> in SerialHandler aufsammeln und komplett an Message übergeben, anstatt addByte und isFull zu benutzen); oder alternativ Ingo überzeugen, das Streaming-Format sinnvoll zu gestalten ;)
Danny Baumann schrieb: > Du musst also etwas umbauen (Nachricht in std::vector<uint8_t> in > SerialHandler aufsammeln und komplett an Message übergeben, anstatt > addByte und isFull zu benutzen); oder alternativ Ingo überzeugen, das > Streaming-Format sinnvoll zu gestalten ;) Ich hatte das damals aus Speichermangel (bei Fehlern max. 256 Bytes), wegen der Geschwindigkeit und Raw-Daten so festgelegt (mega8). Das genaue EMS-Format war zu der Zeit noch etwas schleierhaft und es war einfacher den Puffer, Parser und die Fehlerauswertung auf dem PC zu schreiben als auf dem uC. Egal wie man es macht, man muss immer auf die kompletten Daten warten und dann die Länge + CRC checken, da das Pattern auch in den Daten vorhanden sein kann. Bei der "nicht so" eleganten Methode braucht der uC keinen Zwischenspeicher ;-). Grüße.
>> Du musst also etwas umbauen (Nachricht in std::vector<uint8_t> in >> SerialHandler aufsammeln und komplett an Message übergeben, anstatt >> addByte und isFull zu benutzen); oder alternativ Ingo überzeugen, das >> Streaming-Format sinnvoll zu gestalten ;) > > Ich hatte das damals aus Speichermangel (bei Fehlern max. 256 Bytes), > wegen der Geschwindigkeit und Raw-Daten so festgelegt (mega8). Das > genaue EMS-Format war zu der Zeit noch etwas schleierhaft und es war > einfacher den Puffer, Parser und die Fehlerauswertung auf dem PC zu > schreiben als auf dem uC. Ist ja richtig, aber deswegen muss man das heute doch nicht mehr so machen :) > Egal wie man es macht, man muss immer auf die kompletten Daten warten > und dann die Länge + CRC checken, da das Pattern auch in den Daten > vorhanden sein kann. Bei der "nicht so" eleganten Methode braucht der uC > keinen Zwischenspeicher ;-). Korrekt. Nach allem, was wir inzwischen wissen, reicht aber ein Atmega8 für 2,15€ bei Reichelt für Zwischenspeicherung + EMS-Checksummen-Überprüfung dicke aus ;) Ich wollte ja auch nicht sagen, dass das alles komplett daneben ist, sondern nur, dass Ingo's (bzw. dein) Framing-Format nicht 1:1 zu meinem Daemon passt, weil ich das Format so gewählt habe, dass es leicht zu parsen ist. Mir ist natürlich klar, dass ihr jetzt nicht ohne Not das Format bei euch ändert, weil es - wenn man einmal eine lauffähige Lösung hat - im Prinzip sinnlose Arbeit ist...
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 |
Danny Baumann schrieb: > Mir ist natürlich klar, dass ihr jetzt nicht ohne Not das Format bei > euch ändert, weil es - wenn man einmal eine lauffähige Lösung hat - im > Prinzip sinnlose Arbeit ist... Hallo, hatte auch schon mal vorgehabt das Format etwas zu ändern. Wollte es eigentlich um zwei Byte kürzen die eigentlich Sinnlos sind. Das wären das letzte 0-Byte wo inzwischen klar ist dass es nicht zu den Daten gehört sondern nur ein Break ist. Und dann das Längenbyte am Ende. Werden bei mir eigentlich auch ignoriert. Die Telegramme haben ja eine Prüfsumme. Wenn die Prüfsumme nicht stimmt ist das Telegramm falsch oder unvollständig und nutzlos. Aber irgendwie macht es ja nicht wirklich Sinn noch mein PC-Programm zu ändern. Außerdem könnte es ja theoretisch passieren das die Zeichen AA 55 hintereinander in den Daten stecken und dann als Fehlerhaftes Trennzeichen verstanden werden. Dann macht es schon mehr Sinn die Daten Hexadezimal(text) mit CR/LF am Ende zu senden oder eben das 3964R-Protokoll. Aber habe bisher noch kein einziges mal diese AA 55 in den Daten gesehen. Außerdem habe ich noch genug andere baustellen. Schön dass sich hier mal wieder ewas mehr tut... Gruß Ingo
Nabend, ich wollte erstmal versuchen einzelne Telegramme zuempfangen bevor ich die CRC & Länge auswerte. Aber daran scheitere ich gerade. Die Telegramme die ich bisher gesehen habe wurden immer sauber m_recvBuffer erkannt. Kann sein das es an Ingo's PIC SW liegt ;-) Werde mich da mal weiter reinfuchsen und versuchen C++ zulernen ;-) Ist nicht einfach sich in "fremden" Quelltext einzulesen wenn man die Sprache nicht kenn und alles erst googeln muss.. Da ich in Zukunft gerne auch einfache Sachen ändern wollen würde, fände ich es gut wenn wir uns auf ein (Sende-)Format einigen könnten... Wenn ich die Diskussion hier richtig verstanden habe, sind die Nachrichtenformat (länge, etc.) von der HW & SW abhängig. Macht es da Sinn das in den MC zupacken? Gruß Kay
Hallo, guten Tag und zuerst mal vielen Dank für die viele Arbeit, die ihr in das Vorhaben steckt. Wäre es euch möglich, ein paar Forenbeiträge zu pinnen, und zwar die, in denen lauffähige Hardware und passende Software vorgestellt wird? Grund: Für den Quereinsteiger ist es schwierig, in diesem riesigen Thread (und den damit verlinkten) den Überblick zu bekommen. Wäre schön, wenn das realisiert werden könnte. heiner
Nachtrag zu meinem obigen Beitrag: Ich benötige eine "einfache" Schaltung, um am Servicekey die Daten auslesen und eine Software, um diese auswerten zu können. Als Nichtelektroniker (der aber löten kann) mit geringer Programmiererfahrung (Delphi / Lazarus, Java) habe ich die passenden Beiträge nicht gefunden. Bei mir liegt noch ein USB 2 seriell-Adapter rum, den müßte ich doch eigentlich verwenden können, oder? (Einen Rechner mit RS232-Schnittstelle hab ich nicht mehr) Vielen Dank für eure Hilfe. heiner
heiner2904 schrieb: > Bei mir liegt noch ein USB 2 seriell-Adapter rum, Hallo Heiner, sorry, das wird vermutlich nciht gehen. Auf dem EMS-Bus werden Telegramme mit BREAK beendet. Ein PC ist definitiv zu langsam um das Break Zeichengenau zu erkennen. Mein FTDI-USB-RS232-Wandler kann das Break über den USB-Bus nicht übermitteln. Vermutluch wird das Dein USB-Seriell-Wandler das auch nciht können. Also wird es ohne einen Mikrocontroller der das Break auswertet nicht gehen. Gruß Ingo
Nabend, hat jemand schon die Daten der SM10 decodiert? src dest type 1 2 3 4 5 6 7 8 9 10111213141516 30 00 97 00000002011e01c50301f6ff00000800 30 00 97 00000001f43c01d80301f71400008e00 30 00 97 00000001680001d40101f74500008400 Byte 4 & 5 sind die Kollektor Temperatur Byte 6 die Solarpumpe in % Byte 7 & 8 Speichertemperatur unten Byte 10,11,12 Betriebszeit Solar Was mir noch fehlt ist die Speichertemperatur mitte (45 Grad in den oberen beiden Werten). In der Anzeige gibt es noch einen Solarenzugewinn.... Wie habt Ihr die Werte der anderen Module ermittelt bzw. heraus gefunden? Danke und Gruß Kay
Kay F. schrieb: > Nabend, > > hat jemand schon die Daten der SM10 decodiert? > > src dest type 1 2 3 4 5 6 7 8 9 10111213141516 > 30 00 97 00000002011e01c50301f6ff00000800 > 30 00 97 00000001f43c01d80301f71400008e00 > 30 00 97 00000001680001d40101f74500008400 > > Byte 4 & 5 sind die Kollektor Temperatur > Byte 6 die Solarpumpe in % > Byte 7 & 8 Speichertemperatur unten > Byte 10,11,12 Betriebszeit Solar Byte 2 ist der Betriebszustand Byte 3 ist der Fehlercode Byte 9 ist der Betriebsstatus ... sagt zumindest das Buderus-Dokument, das ich hier habe. > Was mir noch fehlt ist die Speichertemperatur mitte (45 Grad in den > oberen beiden Werten). In der Anzeige gibt es noch einen > Solarenzugewinn.... Das Buderus-Dokument sagt dazu: Die Speicher 1 Mitte Temperatur erhalten Sie über die Standard-Warmwasserparameter. Diesen Temperaturwert erhalten Sie unter dem Offset 1 + 2 ... das wäre dann die Warmwasser-Isttemperatur aus den WW-Monitordaten. Solarer Zugewinn ist in dem Dokument nicht enthalten. > Wie habt Ihr die Werte der anderen Module ermittelt bzw. heraus > gefunden? Größtenteils kollaboratives Reverse Engineering ;) Ein paar Details hat das erwähnte Buderus-Dokument beigesteuert. Das habe ich von Buderus zugeschickt bekommen, als ich einfach mal per Mail angefragt hatte. Alles steht da aber auch nicht drin, nur Kram, der 'User servicable' ist.
Was hast Du denn genau bei Buderus angefragt? Als Endkunde? Würde dann auch mal eine Anfrage starten um dich nicht ständig nerven zu müssen ;-) Gibt es in dem Dokument auch eine Auflistung des Byte 9 (Betriebsstatus)? Ich würde vermute das das 2. Bit für die Pumpe ist. Bei den ersten beiden Daten war die aktiv (30% bzw. 60%) beim letzen aus 00 %. Aber wofür sind die anderen Bits??? Es gibt auch noch eine andere Meldung wenn die Solar Pumpe aktiv ist. Der Inhalt war heute konstant der selbe. src dest type 1 2 3 4 5 6 30 08 35 00000000ce00
Hallo, bin gerade fleissig dabei meiner PCSoftware und der PIC-Firmware das Senden beizubringen und habe gerade meine Heizung nicht dabei ;-) Generell ist der EMS-Telegrammaufbau ja folgender:
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
Hi Niffko, ich habe deine Schaltung nachgebaut und in Betrieb genommen, aber leider kommt übers Terminal (9600 8N1) nichts, hast du Debugbefehle oder so etwas definiert, das man den Controller testen kann? Oder gibt es bestimmte Fuses die man noch setzen mußte? Gruss Norbert
Hi Norbert, was macht denn die LED (die du natürlich entgegen dem Schaltplan richtig herum eingelötet hast)? Sie müsste bei jedem erkannten BREAK toggeln. //Niffko
Hi, die Led macht nichts, du hast auch die 5V und GND vom Atmel vertauscht.
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
Hi Niffko, abschalten des Clockdividers könnte ich vergessen haben. Muss ich am Montag mal prüfen. Gruss Norbert
IngoF schrieb: > heiner2904 schrieb: >> Bei mir liegt noch ein USB 2 seriell-Adapter rum, > > Hallo Heiner, > > sorry, das wird vermutlich nciht gehen. Auf dem EMS-Bus werden > Telegramme mit BREAK beendet. Ein PC ist definitiv zu langsam um das > Break Zeichengenau zu erkennen. > > Mein FTDI-USB-RS232-Wandler kann das Break über den USB-Bus nicht > übermitteln. Vermutluch wird das Dein USB-Seriell-Wandler das auch nciht > können. > > Also wird es ohne einen Mikrocontroller der das Break auswertet nicht > gehen. > > Gruß > Ingo ich habe zwei USB-RS232, eine FTDI und eine PL2303 . Ich glaube das die PL2303 compatibel ist mit die SErviceKey und the Buderus SW. Ich will es ausprobieren später. Ich wolle die USB-RS232 mit eine Synology NAS brauchen, und damit die data von Buderus speichern, aber ist er eine program zuma analysieren? Besser wird die Synology auch einfach Ein/Aus command stueren, dan kann ich es verbinden mit Home automation :) Nicht Einfach ... danke zu help
> ich habe zwei USB-RS232, eine FTDI und eine PL2303 . > Ich glaube das die PL2303 compatibel ist mit die SErviceKey und the > Buderus SW. > Ich will es ausprobieren später. > Es geht mit dit PL2303 & service Key
PL2003 working example with servicekey (eb) http://cgi.befr.ebay.be/ws/eBayISAPI.dll?ViewItem&item=170833794884
Ups... hatte das wohl falsch verstanden. Dachte Du wolltest einfach nur den USB-Adapter an die Heizung mit dem "Pegelwandler" klemmen... Wenn Du den nur als Verbindung zwischen Service-key und PC benutzen möchtes gibt es natürlich keines von meinen genannten Problemen... Gruß IngoF
Hallo, ich habe mich nun durch den für mich verständlichen Teil dieser extrem riesigen Informationssammlung gelesen und muss gestehen dass ich da wirklich etwas Defizite habe. Ich habe so eine Buderus anlage mit einem Klinken-Steckeranschluss und würde eigentlich gerne die Daten die da kommen loggen. Steuern wäre zwar nett aber nicht zwingend nötig. Nun bin ich komplett durcheinander durch die Flut an Informationen hier und frage mich ob das für mich als elektronisch komplett unbeleckten möglich sein könnte ohne Gefahr für meine Heizungselektronik ein Interface zu bauen oder zu kaufen welches mit entweder auf USB oder RS232 die Daten rausgibt. Auf Softwareseite wäre ich dann wieder etwas bewanderter und würde z.B. mit einem Raspberry Pi die Daten loggen und ins Netzwerk weiterreichen. Kann mir jemand dein einfachsten/schnellsten Weg aus der Fülle an Wegen (so sieht es für mich aus) nennen wie ich von dem Klinkenstecker auf RS232/USB kommen könnte? gruß, Daniel
Moin, es geht hier um 2 unterschiedliche Anlagen, um deine geht es auch ;-). Daniel Kirstenpfad schrieb: > Kann mir jemand dein einfachsten/schnellsten Weg aus der Fülle an Wegen > (so sieht es für mich aus) nennen wie ich von dem Klinkenstecker auf > RS232/USB kommen könnte? Es wurden im Thread 3 Möglichkeiten für den Abgriff beschrieben. Eine Platine mit PIC von Ingo: Beitrag "Buderus EMS-"Gateway" mit PIC18F / Sammelbestellung", back to the roots von Niffko: Beitrag "Re: Logamatic 2107 Schnittstelle" , Beitrag "Re: Logamatic 2107 Schnittstelle" und meine Wenigkeit (damals) Beitrag "Re: Logamatic 2107 Schnittstelle" mit ADCMP370 und jetzt einer etwas erweiterten Version mit Opto und TX-Möglichkeit. Die Buderus-EMS ist eine Stromschnittstelle auf der "TX-Seite", wobei der Master jeweils jedes Telegramm auf einer Spannungsschnittstelle wiederholt. Sprich, du greifst das Echo zum Loggen ab, dieses Signal ist TTL-Level, aber mit einem Offset von ~10V. Ich werde demnächst noch eine (oder mehrere) Platinen für einen Receiver bauen, der Prototyp läuft soweit und ist weitgehend digital realisiert. Die Anbindung erfolgt per 3V3/GND und RX/TX-Uart. Grüße.
Hallo, ich bin immernoch auf der Suche nach einer Möglichkeit meine Daten der GB162 abzugreifen. Ich hatte bereits mit IngoF gesprochen, leider fehlen ihm für eine zweite Revision seiner Platine noch ein paar Sachen, daher meine Bitte an dich, Rudi. Solltest du in nächster Zeit mal eine Platine bauen bzw. über haben würde ich sie dir gerne abkaufen. Melde dich bitte mal einfach bei mir spooniester(AET)gmailDOTcom , vielleicht können wir uns per Mail etwas mehr austauschen! Vielen Dank!!
Fast richtig.. Eigentlich ist noch die Zeit bei mir knapp und noch zu gutes Wetter draußen... Aber es sind auch nur drei Leute auf der Warteliste. Unter zehn lohnt sich das nicht wirklich der ganze Aufwand. Bei der zweiten Version würde das allerdings dann nur über 100% Vorkasse laufen können. Will nicht noch mal teilweise dem Geld hinterherlaufen. Gruß IngoF
Hallo Rudi, wärst du so nett uns deine aktuelle Schaltung zu zeigen? Gruss Norbert
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.
Die Nachrichten sind nicht richtig. Sieht nach Polling und Datenmüll aus. Grüsse.
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.
Kostadin schrieb: > warum??? Die Nachrichten sind so aufgebaut: Sorry, falscher Bus ;-). Evtl. passt die CRC vom EMS-Bus? Grüße.
Norbert Schnitzler schrieb: > wärst du so nett uns deine aktuelle Schaltung zu zeigen? Kann ich die Tage mal tun. Ich habe von der Schaltung bisher nur einen Prototypen am laufen ohne Sendefunktion.
Rudi schrieb :
> Sorry, falscher Bus ;-). Evtl. passt die CRC vom EMS-Bus?
1. Macht nichts ;)
2. Tja, leider nicht. Das war meine erste Gedanke. Ich habe auch
versucht irgendwie von EMS-CRC zu BF-CRC (mit XOR) zu kommen - leider
ohne Erfolg.
Bruteforce hat auch keine Lösung gefunden. Ich habe ausprobiert alle
mögliche Kombinationen mit:
- Startwert: 0 bis 255
- Initialwert: 0 bis 255
- final XOR: 0 bis 255.
Fehler sind nicht ausgeschlossen.
Ich bin auch nicht sicher, ob ich die CRC über die ganze Nachricht (11
bytes) machen soll, über die Bytes vor dem CRC Wert (9 bytes) oder nur
über die Nutzdaten (das sind IST_TEMP, SOLL_TEMP Tag, SOLL_TEMP Nacht,
Status): ???
- 11 bytes komplette Nachricht "2: fa 00 01 07 00 1c 14 01 CRC af 04"
- 9 bytes Nachricht: "2: fa 00 01 07 00 1c 14 01 CRC .. .."
- nur die Nutzbytes: "2: .. .. 01 07 .. 1c 14 01 CRC .. .."
Ich weiß, dass wenn man nur ein Bit geändert wird in die Nachricht, dann
ändert sich auch die CRC. Es gibt aber auch unterschiedliche
Nachrichten, welche die gleich CRC haben.
Kann ich irgendwie 3-4 Nachrichten nehmen, bei der nur ein Bit sich
ändert und das Algorithmus irgendwie rauskriegen??? :)
Vielen Dank im Voraus!
Grüße
Kostadin.
Der Ansatz mit dem einen bit ist garnicht mal so verkehrt. So kann man auf jedem Fall schon mal herausbekommen ob bei der CRC-Berechnung noch irgendwas rotiert wird. Am besten mal eine Menge an Telegrammen loggen und dann aus der ganzen Wust mehrere Telegramme herasusuchen wo sich nur ein Bit ändert. Am besten auch mehrer verschiedene Telegrammpärchen nehmen wo sich nur das einzige Bit ändert. Dannach dann andere Telegramme heraussuchen wo sich dann ein anderes Bit ändert. Wenn sich jedes mal genau das Bit in der Prüfsumme ändert was sich in den Daten geändert hat dann ist schon mal keine Rotation mit drin. Wenn sich ein ganz spezielles Bit (z.B. Byte 7 Bit5) ändert und sich in der CRC mehrere Bits ändern oder immer ein anderes Bit in der CRC ändert dann kann es keine simple Verknüpfung mehr sein sondern irgend was mit Generatorpolynom. (CRC4,CRC16 und was es da alles so gibt..) Das ist zumindest die Meinung die ich mir so zurecht gelegt habe. Hoffe das es auch der Relität entspricht ;-D Gruß IngoF
Achso... am besten ein Bit aus den Daten nehmen was sich ändert und nicht aus dem Header. dann ist es zumindest egal ob die Prüfsumme nur über die Daten oder die komplette Nachricht ist... Gruß Ingo
Sieht nicht nach einfach aus: 0xFA 0x00 0x00 0xFC 0x00 0x30 0x28 0x01 0x79 0xFA 0x00 0x00 0xFB 0x00 0x30 0x28 0x01 0x41 Scheint wieder eine "richtige" crc zu sein.
Hallo Rudi, Klingt noch ganz logisch. Muss also keine "richtige" CRC sein... Von 0xFB nach 0xFC ändern sich drei zusammen hängende Bits und in der Prüfsumme ändern sich auch drei zusammenhängende Bits Datenbyte: FB = 1111 1011 FC = 1111 1100 ============== XOR 0000 0111 Prüfsumme: 79 = 0111 1001 41 = 0100 0001 ============== XOR 0011 1000 Die Bits sind entweder 3 mal nach links rotiert oder 5 mal nach rechts. Ich tippe auf 5 mal rechts rotiert. Das geänderte Byte ist 5 Zeichen vor der Prüfsumme. Gruß Ingo
Ingo F. schrieb: > Die Bits sind entweder 3 mal nach links rotiert oder 5 mal nach rechts. > Ich tippe auf 5 mal rechts rotiert. Das geänderte Byte ist 5 Zeichen vor > der Prüfsumme. So einfach ist es leider nicht. Ist evtl. doch ein schlechtes Beispiel gewesen ;-). Hier ein besseres (g): 0xFA 0x00 0x00 0xFB 0x00 0x2E 0x26 0x01 0x01 0xFA 0x00 0x00 0xFB 0x00 0x2E 0x26 0x02 0x98
Die Daten sind noch verpackt in einem Pre-/Suffix:
=> 0xAF <ADRESSE-EMPÄNGER> ; HELLO BFU
<= 0xAC ; Richtungsumkehr
=> 0xA0 ; REQ
<= <DATEN-BFU> ... 0xfa ....... <crc>
<= 0xAF <ADRESSE-SENDER>
=> 0xA4 ; OK
Wenn ich das richtig verstanden habe.
Am Sichersten ist es wenn sich auch nur ein Bit verändert Also z.B 0x33
>> 0x37
Wenn man das ganze an Verschiedenen Bits aus verschiedenen Datenbytes
macht könnte man feststellen ob sich auch nur wirklich immer ein
bestimmtes Bit in der Prüfsumme ändert.
Oder einfach nach der Prüfsumme sortieren bei der sich ein bestimmtes
Bit ändert und dann sehen wo sich Bits ändern können. Das sollte
zumindest bei einer XOR-Prüfsumme mit weiteren Verknüpfungen und
rotationen funktionieren.
Hänge mal die OpenOffice Datei an. Die lässt sich bestimmt dafür
gebrauchen.
Dort werden die Hex-Werte in Binärwerte umgewandelt.
Viel Spasß beim Forschen....
Gruß
Ingo
Hallo Leute,
vielen Dank für den Vorschägen. So was habe ich heute versucht und etwas
gefunden. :)
Ich habe zum Erst untersucht was passiert, wenn man das letzte Byte vor
dem CRC Wert um einen Bit ändert und das Ergebnis ist folgendes:
Status Byte (letzte Byte vor dem CRC) CRC
Bits Bits
x x x x x x x x x x x x x x x x
|^ CRC(neu) = CRC(alt) XOR 0x80
i 6 5 4 3 2 1 0| CRC(neu) = CRC(alt) XOR (19h << i)
z.B. :
Datenbyte : F0 = 11110000 CRC = 10000110
Datenbyte : F1 = 11110001 CRC = 00000110 (CRC(f0) XOR 0x80)
Datenbyte : F3 = 11110011 CRC = 00011111 (CRC(f1) XOR (0x19<<0))
Datenbyte : F4 = 11110100 CRC = 10110100 (CRC(f0) XOR (0x19<<1))
usw.
So, dann habe ich gleich dasselbe mit dem IST_TEMP untersucht:
MSB IST_TEMP CRC
x x x x x x x x x x x x x x x x
^ ^
CRC(neu) = CRC(alt) XOR (0x04)
Bemerkung: bei dem MSB ändert sich nur das erste Bit.
LSB IST_TEMP CRC
x x x x x x x x x x x x x x x x
|^ ^ ^ ^ ^ ^ ^ ^ ^ ^
d.h. wenn sich das erste Bit(bit=0) ändert toggelt sich beim CRC das
vierte Bit(bit=3)
bit1 -> bit4
bit2 -> bit5
bit3 -> bit6
bit4 -> bit7 und noch
x x x x x x x x
i 2 1 0| CRC(neu) = CRC(old) XOR (19h << i)
z.B. :
Datenbyte : F8 = 11111000 CRC = 11001100 CC
Datenbyte : FA = 11111010 CRC = 11011100 DC
Datenbyte : D8 = 11011000 CRC = 11010101 D5
Datenbyte : F8 = 11111000 CRC = 11001100 CC CRC(d8) XOR (0x19 << 0)
So war ich begeistert, dass das gleiche war wie oben.
Dann aber beim SOLL_TEMP taucht wieder dieses (19<<i), aber die Bits
vorne haben andere Einflüsse:
SOLL_TEMP_TAG CRC
x x x x x x x x x x x x x x x x
^ ^
^ ^
^ ^
i 4 3 2 1 0| CRC(neu) = CRC(alt) XOR (19h << i)
z.B. :
Datenbyte : 28 = 00101011 CRC = 10011100
Datenbyte : 2B = 00101000 CRC = 10011100
Datenbyte : 29 = 00101001 CRC = 00000111
Datenbyte : 2D = 00101101 CRC = 10000111
usw.
Was ich auch noch gefunden habe ist wie man die Stelle in Datenbyte
findet, bei der dieses XOR (19<<i) beginnt:
Stelle(bit number) = 8 - (n.Byte vom Nachricht - 1)
Stelle(bit number) = 0x80 >> (n. Byte - 2)
z.B. :
Status Byte ist das 8.Byte in der Nachricht -> Stelle ist bit1.
SOLL_TEMP_TAG ist 6. Byte -> Stelle ist bit3
SOLL_TEMP_NACHT ist 7.Byte -> Stelle ist bit4
LSB IST_TEMP ist 4. Byte -> Stelle ist bit5
MSB IST_TEMP ist 3. Byte -> Stelle ist bit6
So konnte ich auch feststellen an welche Stelle sich das erste Bit
(bit0) jedes Datenbytes sich an welche Bitstelle in CRC sich wirkt:
CRC Bit Stelle bitX, welche sich ändert, wenn das bit0 von dem
Datenbyte sich ändert:
bitX = 0x80 >> (8 - n. Byte + 1)
z.B. :
SOLL_TeMP_TAG 6.Byte -> Das Bit7 toggelt sich wenn beim SOLL_TEMP_TAG
bit0 sich toggelt.
Ich glaube wir sind kurz davor das zu knacken..aber irgendwie weiss ich
nun nicht mehr was zu machen. Vielleicht jemand von euch hat eine Idee?
Grüße.
Kostadin schrieb: > Ich habe zum Erst untersucht was passiert, wenn man das letzte Byte vor > dem CRC Wert um einen Bit ändert und das Ergebnis ist folgendes: Kannst du bitte mal die Reihe von 0x00-0xff aufnehmen? Also Letztes Datenbyte und CRC, bitte beide als Hex-Werte. Dann hätten wir etwas wie die CRC-Table.
Leider es ist nicht möglich das letzte Datenbyte von 00-ff aufzunehmen. Es gibt nur folgende Möglichkeiten: DB CRC 00 C1 01 41 02 D8 03 58 04 F3 05 73 06 AF 07 6A 12 10 13 90 16 22 17 A2 ;)
Hallo, habe mich seinerseits auch mit der CRC der BFU beschäftigt und bin auch nicht weiter gekommen. Vielleicht helfen euch meine aufgenommen Daten weiter. (ohne leading 0xFA 0x00 ).
Ich denke der einfachste Ansatz wäre die CRC-Tabelle zu rekonstruieren. Kostadin schrieb: > Leider es ist nicht möglich das letzte Datenbyte von 00-ff aufzunehmen. > Es gibt nur folgende Möglichkeiten: Sind die Daten vor dem letzten Byte wirklich immer gleich?
Rudi schrieb: > Sind die Daten vor dem letzten Byte wirklich immer gleich? Ja, leider das letzte Byte ist quasi das Betriebsbyte (Status) und es gibt nicht so viele Möglichkeiten dabei - Tag/Nacht, Automatik/Manuell, Sommer/Winter und Urlaub. Sogar einige Werte habe ich gekriegt nur beim Umschalten zwischen einzelnen Betrieben. Ich hänge auch eine Excel-Datei mit aufgezeichneten Daten und deren "Dekodierung" ;) Ich schreibe gerade Funktionen, die die von mir oben genannten Algorithmen umsetzten, so dass ich nur von einer Nachricht+CRC die neue CRC für eine beliebige gewünschte Nachricht bauen kann. Ich sag Bescheid, wenn das funktioniert ;) Herbert Nachbagauer schrieb: > Hallo, > habe mich seinerseits auch mit der CRC der BFU beschäftigt Hallo, hast du zufällig eine BFU mit Funkuhr?? Weil, die BFU, die ich benutzte ist ohne und ich frage mich, ob die Bytes <0x00> und <0x00> zwischen den 0xFA <0x00> MSB_IST_TEMP LSB_IST_TEMP <0x00> SOLL_TEMP_TAG.... immer 0x00 bleiben oder nicht? Ich kann mir schon vorstellen das das 2. <0x00> Byte die Zeit überträgt. Grüße.
Kostadin schrieb: > Hallo, hast du zufällig eine BFU mit Funkuhr?? Weil, die BFU, die ich > benutzte ist ohne und ich frage mich, ob die Bytes <0x00> und <0x00> > zwischen den > > 0xFA <0x00> MSB_IST_TEMP LSB_IST_TEMP <0x00> SOLL_TEMP_TAG.... > > immer 0x00 bleiben oder nicht? Ich kann mir schon vorstellen das das 2. > <0x00> Byte die Zeit überträgt. BFU/F habe ich keine. Ein byte is aber auch schon für minutengenaue Werte 24*60 = 1440 zu klein. Ich vermute es gibt eher einen eigenen Message Typ mit Header 0xFA ?? (analog er 2107 Antwort mit 0xFA 0x06) und zwei (drei) Nutzdatenbytes HH, MM, (SS).
Hallo wieder,
nun habe ich die Funktionen umgesetzt und nach ein paar Änderungen, die
funktionieren ohne Probleme. :)) Leider das ist nicht die CRC Berechnung
selbst, aber zumindest können wir jetzt Nachrichten senden..(vermute ich
mal).
>@Rudi
ich habe mittels die Funktionen für das letzte Byte (00-FF) die CRC
berechnet. Die DB und dazugehörige CRCs sind in die 2. Datei. Ich hoffe
du kannst die CRC-Tabele restaurieren. Ich weiß nicht was zu machen mit
diesen Werten. Vorschläge?
Grüße.
Hallo, Hab gerade mit optokoppler und 3.5mm klinke meine Buderus daten entlockt. Interface ist ATmega8 mit etwas geanderter firmware (macht clear text). Danke fuer die super (wenn auch wusselige) info ;-) ohne eure arbeit waere das bei mir etwas laenger gewesen. Einen scope hatte ich schon dran aber dann stiess ich auf diesen tread. Eine Frame die ich noch nicht viel info hier lese ist diese: Sun Oct 14 07:40:47 UTC 2012 : 1000A30008010100CA00D000D07D007D00FC00 Daraus habe ich gefunden: 00CA = inside temp = 20.2°C ??? ==> Confirmed 00C9 = 20.1 Gibt es irgendwo eine uptodate liste? Schoenen Sonntag Edward
Hallo Niffko _, ich programmiere z.Z. meine Rücklaufanhebung und habe ein paar Fragen bezüglich Heizungsinterna. Evtl. könntest du mir etwas auf die Sprünge helfen. Bei einer relativ hohen VL Solltemperatur (z.Z. 52°) und großem dT zwischen RL und VL (z.Z. 20°C) wollte ich den Rücklauf nicht ganz anheben, sondern nur soweit dass die Heizung im unteren Leistungsbereich mitläuft. Gibt es einen Richtwert für VL soll/VL/RL wann die Heizung wieder einschaltet? Was gibt die Heizungsleistung (in %) aus den Logdaten genau an, aus welchen Heizungsparameter wird diese errechnet? Korreliert der gemessene Flammenstrom mit dem Gasverbrauch? Danke & Grüße.
Hallo Rudi, na, Saison eröffnet? Bei mir geht's auch schon wieder los ^^ Rudi schrieb: > Gibt es einen Richtwert für VL soll/VL/RL wann die Heizung wieder > einschaltet? Die Einschalthysterese des Brenners beträgt -6K. Rudi schrieb: > Was gibt die Heizungsleistung (in %) aus den Logdaten genau an, aus > welchen Heizungsparameter wird diese errechnet? Das ist die momentane Brennerleistung bezogen auf die Nennleistung deines Heizkessels. Errechnet wird sie über die Drehzahl des Gebläses (Tachosignal). Das ist möglich, weil die Gasarmatur die Gasmenge entsprechend des vom Gebläse erzeugten Unterdruckes regelt. Der UBA macht die Leistungsregelung mittels PWM-Signal für das Gebläse und erhält als Rückkopplung das Tachosignal derselbigen - welches dann auf Ist-Leistung umgerechnet wird. Rudi schrieb: > Korreliert der gemessene Flammenstrom mit dem Gasverbrauch? Prinzipiell ja - stärkere Flamme, mehr Flammensrom. Ist aber nur als Tendenz zu gebrauchen. Zu viele Unbekannte ... Übergangswiderstände, Belag auf der Elektrode. Solltest du den Gasverbrauch erfassen wollen, nimm die Ist-Leistung. Ich lasse meinen µC alle 5s die Ist-Leistung aufaddieren und errechne in der PC-Applikation über Nennleistung und Heizwert[kWh/m³] den Gasverbrauch. Ist für meine Zwecke genau genug. //Niffko
Hallo Niffko, Niffko schrieb: > na, Saison eröffnet? Bei mir geht's auch schon wieder los ^^ Ja und der Umbau für die Rücklaufanhebung ist auch fertig geworden :-). > nimm die Ist-Leistung. Ich lasse meinen µC alle 5s die Ist-Leistung > aufaddieren und errechne in der PC-Applikation über Nennleistung und > Heizwert[kWh/m³] den Gasverbrauch. Ist für meine Zwecke genau genug. Ich lese den Gaszähler direkt aus und bekomme die Impulse und kann somit die Tages/Stunden ... Ration für den Brenner berechnen. Nun ein weiteres Problem, was ich erfolgreich verdrängt habe. Die Heizungspumpe bleibt bei 100%iger Rücklaufanhebung bei bescheidenen 55% und die Heizkörper werden jetzt sehr sehr Träge warm VL: 52°C/RL 35°C. Der Heizkreis schiebt also nicht genug Wärme nach bzw. der Unterdruck im RL fehlt :-/. Bei der RC30 konnte man die Pumpe nicht ansteuern oder? Bei der RC35 konnte die Pumpe über das EMS-Interface umgeschaltet werden oder evtl. auch geregelt!? Von welchen Parametern hängt die Pumpleistung eigentlich ab? Grüße.
Angehängte Dateien:
Hallo, so sieht z.Z. meine mobile "Heizungsüberwachung" aus. Der Server stellt die Seite im Netz bereit (jquery mobile) und die Daten werden per Ajax regelmäßig neu geladen. Wen es interessiert ;-). Grüße.
Moin Rudi, Rudi schrieb: > Heizungspumpe bleibt bei 100%iger Rücklaufanhebung bei bescheidenen 55% > [...] > Von welchen Parametern hängt die Pumpleistung eigentlich > ab? Die Pumpenmodulation ist bei der GB152 an die Brennerleistung gekoppelt. Demzufolge läuft die Pumpe bei 'Brenner AUS' auf Minimum. Rudi schrieb: > Bei der RC30 konnte man die Pumpe nicht ansteuern oder? Bei der RC35 > konnte die Pumpe über das EMS-Interface umgeschaltet werden oder evtl. > auch geregelt!? Geht leider bei GB152 nicht ... egal mit welcher Regelung. Die Arten der Pumpenansteuerung werden durch das Heizgerät definiert. GB142, GB162 und GB172 können z.B. auch Differenzdruckregelung. Damit hättest du das Problem nicht. Mögliche Optionen: - Steuerkabel der Pumpe abziehen, dann läuft sie Volllast - Steuersignal(PWM) der Pumpe hacken und Pumpe mit eigener Hardware ansteuern Wie hast du denn die WW-Bereitung in die Rücklaufanhebung eingebunden? Es kann da bei Kombipuffern fiese Fehlzirkulationen geben. Hängt damit zusammen, dass der GB152 das 3-Wege-Umschaltventil im Rücklauf hat und Heizungs- und WW-Vorlauf verbunden sind. //Niffko
Rudi schrieb: > Hier der Code: > poly = 12 > crc1 = 0x00 > > for i in range(0,len(a)-1): > crc1 = crc1 ^ int(a[i],16) > crc2 = crc1 > if crc1 & 0x80: crc1 ^= poly > > d = 0 > if crc1 & 0x80: d = 1 > crc1 = crc1 << 1 > crc1 &= 0xfe > crc1 |= d > > => crc2 Hallo Rudi, ich versuche mich gerade daran diese Formel umzusetzen, stehe aber etwas auf dem Schlauch. Wie würde das aussehen, wenn ich die Daten übergebe und CRC zurück bekommen möchte? Also diese Formel als Funktion in PHP umsetzen!? Gruß Thorsten
Moin Niffko, Niffko schrieb: > Rudi schrieb: >> Heizungspumpe bleibt bei 100%iger Rücklaufanhebung bei bescheidenen 55% >> [...] >> Von welchen Parametern hängt die Pumpleistung eigentlich >> ab? > > Die Pumpenmodulation ist bei der GB152 an die Brennerleistung gekoppelt. > Demzufolge läuft die Pumpe bei 'Brenner AUS' auf Minimum. Dann aber per Software bzw. Regelung und nicht hart verdrahtet. > Rudi schrieb: >> Bei der RC30 konnte man die Pumpe nicht ansteuern oder? Bei der RC35 >> konnte die Pumpe über das EMS-Interface umgeschaltet werden oder evtl. >> auch geregelt!? > > Geht leider bei GB152 nicht ... egal mit welcher Regelung. Die Arten der > Pumpenansteuerung werden durch das Heizgerät definiert. GB142, GB162 und > GB172 können z.B. auch Differenzdruckregelung. Damit hättest du das > Problem nicht. > > Mögliche Optionen: > - Steuerkabel der Pumpe abziehen, dann läuft sie Volllast > - Steuersignal(PWM) der Pumpe hacken und Pumpe mit eigener Hardware > ansteuern Ich habe eine andere Option getestet. Über den Relais-Test springt die Pumpe mit 100% an, bleibt dann aber bei 100% bis der Brenner wieder anspringt. Es gab dort auch eine Fehlermeldung, die ich mir mal genauer anschauen muss. Der Test sollte ja auch per EMS funktionieren!? > Wie hast du denn die WW-Bereitung in die Rücklaufanhebung eingebunden? > Es kann da bei Kombipuffern fiese Fehlzirkulationen geben. Hängt damit > zusammen, dass der GB152 das 3-Wege-Umschaltventil im Rücklauf hat und > Heizungs- und WW-Vorlauf verbunden sind. Keine großen Änderungen damit alles so läuft wie gehabt. Das KW für WW geht über den Puffer und im Rücklauf des HK steckt jetzt zusätzlich ein Mischer. Nebenzirkulationen habe ich noch nicht beobachtet. Das WW ist in diesem Setup eher nebensächlich und wird nicht direkt über den Puffer geladen, nur über das KW bei WW-Abnahme. Man könnte jetzt noch eine Pumpe installieren und dann über KW und WW zirkulieren und die Wärme in den WW-Puffer transportieren, ist aber erst mal nicht vorgesehen. Danke für die Infos! Grüße.
Thorsten schrieb: > Hallo Rudi, ich versuche mich gerade daran diese Formel umzusetzen, > stehe aber etwas auf dem Schlauch. Wie würde das aussehen, wenn ich die > Daten übergebe und CRC zurück bekommen möchte? Also diese Formel als > Funktion in PHP umsetzen!? Das ist Python und sollte meiner Meinung nach keine Probleme bei der Portierung bereiten. Grüße.
Ok, aber könntest du mir trotzdem auf die Sprünge helfen? Hier hast du das ja noch einmal vereinfacht:
1 | for i in range(0,len(a)-1): |
2 | d = 0 |
3 | if crc1 & 0x80: |
4 | crc1^=12 |
5 | d = 1 |
6 | crc1 = crc1 << 1 |
7 | crc1 &= 0xfe |
8 | crc1 |= d |
9 | crc1 = crc1^int(a[i]) |
Welches sind denn die Daten die an die Funktion übergeben werden und was sind "i", "a" und "crc1" ? Ich nehme an crc1 wird nur innerhalb der Formel benutzt und ist letztendlich das Ergebnis!? Aber du hast vorher schon ne "IF" Bedingung auf crc1, obwohl das noch nicht definiert ist? Irgendwie verstehe ich den Code nicht :( Gruß Thorsten
Moin 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 | }
|
Moin Niffko, das sieht schon etwas verständlicher aus, aber wofür ist das u8, wenn du es es gleich auf 0 setzt und gar nicht erst benutzt ?? Und du übergibst in "buffer" das Byte Array und in "pos" die Anzahl Bytes!? Wie sieht ein Beispielinhalt deines Arrays aus? Gruß Thorsten
Thorsten schrieb: > Welches sind denn die Daten die an die Funktion übergeben werden und was > sind "i", "a" und "crc1" ? "a" ist der "String" in der die Datenbytes übergeben werden "i" ist der Schleifenzähler "d" ist "crc1" ist der Zwischenspeicher für die Prüfsumme "^" ist ein XOR ">>" ist ein rotieren nach links. Mit ein wenig googlen sollte man das aber auch selber herausbekommen. Die Routine macht nichts anderes als die Bytes mit XOR zu verknüpfen und zu rotieren. Wenn der Zwischenwert 0x80 oder größer ist wird nochmals zusätzlich mit 0x12 verknüpft. Kann ja auch mal meinen Java-code anhängen. Bei mir wird die CRC nach jedem Byte berechnet Am Ende wird dann einfach nur die CRC abgespeichert. Der mittlere Block wird also für jedes Byte wiederholt. Bin noch nicht dazu gekommen das umzuschreiben. Aber im Moment habe ich noch keinen Grund dazu.
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
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
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
Falls es jemanden interessiert: Ich habe meinen EMS-Daemon, den ich weiter oben schon mal gepostet habe, bei Github hochgeladen: https://github.com/maniac103/ems-collector Der Daemon kann entweder per UART oder via TCP (mittels NetIO o.Ä. + Ethersex) mit dem EMS sprechen. Im letzteren Fall kann er auch Kommandos via telnet empfangen und an die Heizung schicken. Wenn jemand noch interessante Sendesequenzen hat: Nur her damit ;)
Danny Baumann schrieb: > Ich habe meinen EMS-Daemon, den ich > weiter oben schon mal gepostet habe, bei Github hochgeladen: Was macht man denn mit den ganzen Dateien? Kann mann die auch komplett herunterladen? Was brauch man denn zum kompilieren? Oder muss man das einfach in einen Ordner schieben und alles läuft von selber?
IngoF schrieb: > Kann mann die auch komplett > herunterladen Ups.. habe gerade gesehen dass es einen Knopf gibt um alles als ZIP herunter zu laden.
IngoF schrieb: > Was brauch man denn zum kompilieren? Oder muss man das einfach in einen > Ordner schieben und alles läuft von selber? Nee, kompilieren musst du schon noch ;) Dependencies sind mysql++ und boost.
Danny Baumann schrieb: > Nee, kompilieren musst du schon noch ;) > Dependencies sind mysql++ und boost. Na dann muss ich das noch ein oder zwei Jahre verschieben ;-) Habe bei mir eine Synology DiskStation212 auf der ich das vermutlich auch gut laufen lassen könnte... Oder kann man deinen EMS-Daemon nicht auf Linux kompilieren? Habe mich damit leider noch nicht richtig beschäftigt... Der FTDI-SerialPort habe ich im ersten Anlauf noch nicht zum laufen bekommen.. Gruß Ingo
IngoF schrieb: > Danny Baumann schrieb: >> Nee, kompilieren musst du schon noch ;) >> Dependencies sind mysql++ und boost. > > Na dann muss ich das noch ein oder zwei Jahre verschieben ;-) > > Habe bei mir eine Synology DiskStation212 auf der ich das vermutlich > auch gut laufen lassen könnte... Oder kann man deinen EMS-Daemon nicht > auf Linux kompilieren? Doch, sicher, warum auch nicht? Ich lasse den Daemon (wie weiter oben schon mal erwähnt...) auf einem SheevaPlug mit Debian Squeeze laufen. Da habe ich allerdings den Vorteil, eine volle Linux-Distro zu haben. Ich hab keine Ahnung, ob es Synology-Pakete für boost und mysql++ gibt.
Hi, dank Danny bekomme ich jetzt auch Daten meiner GB162. Ich lasse den Daemon von Danny auf einem Raspberry mit Rapsbian laufen, klappt wunderbar. Dort liegt auch die MySql Datenbank, keinerlei Performance Probleme! Sogar senden klappt ohne Probleme! Gruß spooniester
Hallo, Niffko schrieb: > Mögliche Optionen: > - Steuerkabel der Pumpe abziehen, dann läuft sie Volllast Werde ich mal Testen. Hast du zufällig eine Belegung des Steuerkabels? > - Steuersignal(PWM) der Pumpe hacken und Pumpe mit eigener Hardware > ansteuern Bist du sicher das PWM benutzt wird? Ich hatte im Zusammenhang Buderus Pumpe mal etwas von 0-10V gelesen. Wenn dem wirklich so ist könnte ich einen analog Schalter/Multiplexer benutzen und dann etwas "einfacher" die Pumpe über feste Spannungen modulieren. Z.Z. -7°C werden die Heizkörper im unteren Bereich nicht richtig warm. Ich steh da jetzt total auf dem Schlauch wie die Heizung erkennt ob Wärme gebraucht wird oder nicht. Die Spreizung VL/RL ist im Mischer- oder Heizungsbetrieb nur marginal unterschiedlich 2-3K. Wie wird denn die Brennerleistung bzw. Pumpenleistung bei der GB152 festgelegt, machen diese 2-3K schon den großen Unterschied? Danke & Grüße, Rudi
Moin Rudi, Rudi schrieb: > Hast du zufällig eine Belegung des Steuerkabels? Nein habe ich nicht. Dürfte aber mit einem Oszi nicht so schwierig sein. Rudi schrieb: > Bist du sicher das PWM benutzt wird? Jep. Rudi schrieb: > Wie wird denn die Brennerleistung bzw. Pumpenleistung > bei der GB152 festgelegt ... Die alleinige Führungsgröße für den Brenner liefert der Vorlaufsensor. Nähert sich die Vorlauftemperatur dem Sollwert, beginnt der Brenner - und damit auch die Pumpe - bis auf min. Leistung herunterzumodulieren. Bei Sollwertüberschreitung von 6K schaltet der Brenner ab und die Pumpe verbleibt auf min. Modulation. //Niffko
Angehängte Dateien:
-
grundfos_uper15_60_pwm.jpg
310 KB -
buderus_uba3.jpg
180 KB
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.
Angehängte Dateien:
-
pwm_2ms.jpg
170 KB -
pwm_55_prozent.jpg
160 KB -
pwm_71_prozent.jpg
170 KB -
pwm_77_prozent.jpg
170 KB -
pwm_100_prozent.jpg
150 KB -
pwm_pulsbreite.jpg
15 KB
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.
Angehängte Dateien:
-
ems_uart_converter.jpg
180 KB
Hallo, anbei mal ein Bild von meinem EMS<->UART-Konverter ;-). Ich hatte heute endlich mal Zeit für die Bestückung. Grüße.
Hallo, ich würde gerne bei meiner neuen Therme GB172 Daten aufzeichnen. Als Hardware habe ich mir den EMS-Reader von Niffko ausgesucht: Beitrag "Re: Logamatic 2107 Schnittstelle" Die Schaltung ist ja relativ simpel und Firmware ist auch verfügbar. Ich würde gerne wissen ob den Reader schon jemand erfolgreich aufgebaut hat und ob er für GB172 geeignet ist. Vielen Dank im Vorraus! Gruß Heisenberg
Angehängte Dateien:
-
EMS_Reader_V1__2_.png
11 KB
Hallo, Heisenberg schrieb: > ob er für GB172 geeignet ist. nicht getestet, aber mit an Sicherheit grenzender Wahrscheinlichkeit - ja ;) In der ursprünglich geposteten Schaltung, hatte ein wenig der Fehlerteufel zugeschlagen - deshalb im Anhang nochmal eine revidierte Version. //Niffko
Hallo, erst mal ein Riesen Chapeau !! für Eure Arbeit am EMS. Ich habe eine Logamatic 2107M und den Verdacht, dass ich noch vieles optimieren kann. Dazu möchte ich zuerst den Ist-Zustand loggen - idealerweise mit einem Raspberry Pi. Bin ich mit diesem Plan hier richtig? Nach zwei Tagen in diesem Monsterfred bin ich verloren, deswegen als Frage formuliert. Weitere Fragen: EMS basiert auf I2C? EMS liegt auf dem Kabel zum Display/Bedieneinheit und auf der Hauptplatine der 2107M am 12poligen Stecker, wo ihn auch das KM271 abgreift? Das KM271 ist "nur" ein Pegelwandler EMS auf RS232 plus Anschluss für Abgastemperatur? An der Klinkenbuchse von RC3x wird das EMS Protokoll auf eine Gleichspannung von 12V moduliert, um Bedieneinheiten mit Spannung und Daten zu versorgen? Sprechen 2107M und RC3x beide (das gleiche) EMS (Protokoll)? Gilt alles, was in den letzten 3 Jahren um EMS erforscht wurde auch für die 2107M? Ich frage deswegen, weil Ingo F. am 25.2.2011, sagt: "Hat ja schon lange nichts mehr mit der Buderus 2107 zu tun." Den Zusammenhang zwischen Service Key, ECO-CAN und EMS erschliesst sich mir nicht. Das 4000er System scheint ein Vorläufer der 2107M zu sein, für mich nicht relevant. Nach meinem Verständnis gibt es folgende Zapfpunkte an der 2107M: 1) Rudi experimentierte im November 2009 mit einem 2107 Bedienteil, was am 24.11.2009 zu einer Platine mit Atmel 644 führte. Diese zapft Daten vom Flachbandkabel zum Display ab. Was kann diese Platine, wo ist sie im Thread dokumentiert? Ich habe es nicht gefunden. Inwieweit ist Rudis Platine vergleichbar mit der von Michael Meyer vom 29.8.2010? 2) KM271 oder Clon Mit Hilfe von Joachim K./himtronics und chipshuffler hat Malte Bayer/hellraiser einen KM271 Clon entwickelt. Der auf der Platine befindliche XPORT stört die Temperaturwerte, wird nur der 232 Zweig bestückt, ist alles OK. Angeblich ist die Version C nicht korrekt, D wurde nie veröffentlicht? 3) EMS Gateway mit PIC18F von Ingo F. Da ich ein Atmel-Kind bin, komme ich da nicht weiter. @Ingo: Klasse Idee mit dem CAN Bus, bin ich auch ein Fan von! 4) EMS UART Konverter von Rudi - wie funktioniert der? 5) EMS Reader von niffko. Wie komme ich am besten, einfachsten, sichersten an die Daten der 2107M und zu einer Langzeit Protokollierung und Darstellung? Gerne trage ich was zum Projekt bei, ich kann: Layouten mit Eagle 5 Platinen doppelseitig herstellen Platinen bestücken - am liebsten bedrahtet, nach 'nem Bier geht auch SMD 0,85 Pitch :-) Atmels programmieren/compilieren/flashen Und demnächst auch Raspberrien... Was ist auf Dauer sinnvoll? 2107M behalten oder ersetzen? Durch was? Sind andere Steuerungen so viel besser, dass der Austausch sich absehbar amortisiert? Ich wünsche Euch allen einen guten Start in 2013! PS: Ich unterstütze den Vorschlag von Malte Bayer/hellraiser vom 17.8.2010 diesen Thread in einen neuen zu überführen! Vielleicht können die Antworten auf meine Fragen als abschliessende Zusammenfassung dienen... :-)
Erstmal allen ein Frohes neues Jahr 2013. Jörg Hermann schrieb: > Ich habe eine Logamatic 2107M und den Verdacht, dass ich noch vieles > optimieren kann. > Dazu möchte ich zuerst den Ist-Zustand loggen - idealerweise mit einem > Raspberry Pi. > Bin ich mit diesem Plan hier richtig? Ja. > Nach zwei Tagen in diesem Monsterfred bin ich verloren, deswegen als > Frage formuliert. > > Weitere Fragen: > EMS basiert auf I2C? Nein. Es ist eine Strom-/Spannungsschnittstelle die die Daten mehr oder weniger in einem UART kompatiblen Format überträgt. > EMS liegt auf dem Kabel zum Display/Bedieneinheit und auf der > Hauptplatine der 2107M am 12poligen Stecker, wo ihn auch das KM271 > abgreift? Ja, aber bei der 2107M wird wohl ECO-CAN gesprochen, nicht EMS. > Das KM271 ist "nur" ein Pegelwandler EMS auf RS232 plus Anschluss für > Abgastemperatur? Ja, wobei der Interface nur eingeschaltet wird wenn ein Abgassensor vorhanden ist. > An der Klinkenbuchse von RC3x wird das EMS Protokoll auf eine > Gleichspannung von 12V moduliert, um Bedieneinheiten mit Spannung und > Daten zu versorgen? Nein. 12V/GND/Daten, diese 3 Leitungen gibt es dort. > Sprechen 2107M und RC3x beide (das gleiche) EMS (Protokoll)? Nein, siehe oben (ECO-CAN?). > Gilt alles, was in den letzten 3 Jahren um EMS erforscht wurde auch für > die 2107M? Nein. > Ich frage deswegen, weil Ingo F. am 25.2.2011, sagt: "Hat ja schon lange > nichts mehr mit der Buderus 2107 zu tun." > Den Zusammenhang zwischen Service Key, ECO-CAN und EMS erschliesst sich > mir nicht. > Das 4000er System scheint ein Vorläufer der 2107M zu sein, für mich > nicht relevant. > > Nach meinem Verständnis gibt es folgende Zapfpunkte an der 2107M: > > 1) Rudi experimentierte im November 2009 mit einem 2107 Bedienteil, was > am 24.11.2009 zu einer Platine mit Atmel 644 führte. > Diese zapft Daten vom Flachbandkabel zum Display ab. Auf dem Kabel gibt es Adressleitungen und eine Messleitung. Die eigentlichen "Messwerte" werden in eine Frequenz konvertiert und von mir nur gemessen. > Was kann diese Platine, wo ist sie im Thread dokumentiert? Ich habe es > nicht gefunden. Garnicht. > Inwieweit ist Rudis Platine vergleichbar mit der von Michael Meyer vom > 29.8.2010? ??? > 2) KM271 oder Clon > Mit Hilfe von Joachim K./himtronics und chipshuffler hat Malte > Bayer/hellraiser einen KM271 Clon entwickelt. Der auf der Platine > befindliche XPORT stört die Temperaturwerte, wird nur der 232 Zweig > bestückt, ist alles OK. Angeblich ist die Version C nicht korrekt, D > wurde nie veröffentlicht? ... > 3) EMS Gateway mit PIC18F von Ingo F. Da ich ein Atmel-Kind bin, komme > ich da nicht weiter. @Ingo: Klasse Idee mit dem CAN Bus, bin ich auch > ein Fan von! > > 4) EMS UART Konverter von Rudi - wie funktioniert der? Der Empfangsteil arbeitet mit einem Komparator der ohne viel Analogelektronik auskommt. > > 5) EMS Reader von niffko. Wurde aus der original Hardware extrahiert. > Wie komme ich am besten, einfachsten, sichersten an die Daten der 2107M > und zu einer Langzeit Protokollierung und Darstellung? Ich würde es an der KM271 Schnittstelle probieren. Das Problem was ich sehe ist der Abgassensor, k.A. wie diese Werte dann in die Heizungsregelung eingreifen. Aus diesem Grund bin ich auch einen anderen Weg gegangen. Grüße.
Hallo, Habe meine Buderus Gasterme mal vor ein paar Tagen einen Druckabfall da kleines Leck (muss den Installateur noch her rufen da neue Installation - 6 Monate) aber der Punkt nachdem ich alles in Ordung gebracht habe (ohne neustart) ist: Das Display zeight Fehler: "OY" wenn ich den "Schraub Schluessel" Knopf ein paar mal druecke. Aber alles laeuft wieder normal und wenn Flamme da ist habe ich "-H" wie gehabt (anstelle "OY") aber nur solange Flamme da ist. Erste Frage: Ist "OY" jetzt nur im "Fehler Speicher" ? (Ich denke sonst waere die Terme ja nicht in betrieb) List der Fehler unter: http://www.buderus.de/sixcms/media.php/1156/05492_KUP_BUD_EMS_Handbuch_L.121878.pdf Denn: Ich habe folgendes telegram: 080018003802CF641C09012560800001B9029D00E40F2D4800_C8_00200F000 C8 ist doch alles OK. Dann habe ich geforscht (in dem Dokument) und "OY" ist entweder 276 dec oder 277 dec, also 0114 oder 0115 hex und habe danach in meinen Telegrammen gesucht und nur hier vom RC35 gefunden: Mon Jan 7 19:30:35 UTC 2013 : 100006000D_0114_07243700003100 Kann es sein dass der RC35 den Fehler auch gespeichert hat? Bevor der Service Man die Terme resetted gibt es hier wohl Gelegenheitsmoeglichkeiten ... Irgend jemand der das nachvollziehen kann? (Oder rede ich als Englaender nur exentrisches Zeug) Edward
Nachtrag: Wenn der Brenner nicht Laeuft habe ich: 0800180038022A640001010060800001B7022300000D305900_CC_0000000C00 CC = 204 dec Im Doku: BetriebsCode "0Y" 204 Die aktuelle Kes-sel wasser tempera-tur ist höher als die Sollkessel was-ser temperatur. Die aktuelle Kesselwasser-temperatur ist höher als die Soll kessel wasser tempe ra-tur. Der Kessel wird abge-schaltet. "Keine Massnahme" Also kein Fehler?
Hallo Edwart, Edward Cardew schrieb: > Also kein Fehler? Nein, kein Fehler ... alles in Ordnung. Dieses 0Y-204 ist vollkommen harmlos und ein normaler Bertiebszustand. //Niffko
Hi Niffko, Ich denk auch, alles OK. Noch ne Frage da ich gerade Telegramme decodiere ... ist der Code nur ein byte oder die 00 davor noch dazu? Die dokus hier in den Excel dateien sind "not obvious" ;-) Ed
Edward Cardew schrieb: > ist der Code nur > ein byte oder die 00 davor noch dazu? Gegenfrage: Wie willst du z.B. 276 oder 277 mit einem Byte darstellen ;) Edward Cardew schrieb: > Dann habe ich geforscht (in dem Dokument) und "OY" ist entweder 276 dec > oder 277 dec //Niffko PS: @all ... nur für die Akten - mein Post vor diesem war der 1000ste. Glöckwoooonsch an alle Beteiligten :))
Niffko schrieb: > PS: @all ... nur für die Akten - mein Post vor diesem war der 1000ste. > Glöckwoooonsch an alle Beteiligten :)) :-) Edward Cardew schrieb: > Noch ne Frage da ich gerade Telegramme decodiere ... ist der Code nur > ein byte oder die 00 davor noch dazu? Die dokus hier in den Excel > dateien sind "not obvious" ;-) failure: 2 bytes (ASCII your favorite encoding ;-)) error code: 2 bytes ...
Gibt es ausser die Excel files oben im Thread no signifikante Forschritte bei dem Mapping von den Telegram Codes? Bei mir huscht so vieles durch den Parser durch und am anderen Ende raus ... ;-) Ed
Edward Cardew schrieb: > Gibt es ausser die Excel files oben im Thread no signifikante > Forschritte bei dem Mapping von den Telegram Codes? > Bei mir huscht so vieles durch den Parser durch und am anderen Ende raus Was genau? Die Wochenzeitschaltung z.B. wurde hier nur im Ansatz geklärt.
Niffko schrieb: > Mögliche Optionen: > - Steuerkabel der Pumpe abziehen, dann läuft sie Volllast > - Steuersignal(PWM) der Pumpe hacken und Pumpe mit eigener Hardware > ansteuern Nochmal danke für den Tipp :-). Z.Z. läuft Methode 1. gesteuert, werde aber die Methode 2. umsetzen um bei einer Teilrücklaufanhebung (Mischer mischt und Brenner läuft) etwas besser Steuern zu können. Wenn nur der Mischer läuft ist es auch etwas suboptimal immer von 55% auf 100% zu springen. Wenn ich fertig bin habe ich mir eine zweite Heizung gebaut ... man man. Grüße.
Hallo Jungs, Ist dieses Thema noch aktuell? Ich versuche auch aktuell unseren GB162 anzuzapfen. Wir haben hier ein RC35 im Wohnzimmer. Da ich aktuell sehr viel mit den RFM70 Modulen arbeite, war meine Idee: Ein Atmega8 mit einem MAX232N dran hängen, die Daten vom EMS über das RFM70 Modul in unseren Hausbus einzuspeisen. Bin aktuell mit dem Schaltplan beschäftigt, die Grundschaltung mit Max232n und RFM70 steht bereits... nun die Frage: Die RFM70 Module arbeiten mit 3,3V die Digital Input Pins kann ich mit Max 5.25V beschalten, also könnte ich den Atmega8 mit +5V laufen lassen, die RFM kriegt dann Ihre 3,3V und hat keine Probleme mehr. Nun die frage, gibt es einen aktuellen Schaltplan? Prinzipiel kann ich ja EMS+ und EMS- direkt an die Eingänge vom MAX232N hängen und die Ausgänge an den Atmega8? Grüße, Daniel
Den GB162 habe ich auch. Den habe ich einfach am 3.5mm Klinke abgehorcht (Service Buchse hinter scharzen Kappe am Front Pannel). Da sind wie oben irgenwo :-) erwaehnt 12 Volt, Gnd und Signal. Mit einem Transistor auf nen Optokoppler laeuft bei mir seit 6 Monate ohne Probleme. Eingriff ins Geraet fuer EMS + und - nicht noetig. Auch Max232 entfaellt und der ATmega Seriel Eingang kann direct an den Opto Ausgang. Aufpassen muss man nur bein reinstecken des Klinken steckers wegen der +12V? Einmal hat es mein Brenner resetet und seitdem mache ich Strom aus bevor ich den rein mache oder raus ziehe. Die info hier im Thread ist gut und viel, doch weit verstreut ... Ed
Zu Beitrag #2977072: Hallo Jörg, viele infos zu KM271 / Logamatik 2107 findest du unter http://wiki.neo-soft.org/index.php/Heizungsschnittstelle/Logamatic2107 bzw http://wiki.neo-soft.org/index.php/Heizungsschnittstelle/Logamatic2107/K4 Grüße Herby
Hallo Leute, ich habe mir hier ein Setup aufgebaut, um meine Buderus Heizung per EMS auszulesen. Ziel der Sache ist es eigentlich die Tag/Nachtschaltung umzuschalten und somit das vorhandene RC25 zu "emulieren". Die Bedieneinheit soll natürlich weiterhin bleiben. Ich habe hier das Ethersex Modul von maniac103 am laufen. Damit habe ich nun mal ne halbe Stunde oder so mitgeloggt und eine Statistik erstellt. Weiterhin habe ich etwas in der Übertragung rumgestochert und folgendes "herausgefunden": Sonne drücken: AA 55 06 17 08 35 00 11 11 2A Mond drücken: AA 55 06 17 08 35 00 01 01 2A Ansonsten war das Langzeitlog im Sonnemodus und der Referenzraum hatte 21.4 - 21.9°C soweit ich das überblicken konnte. Nun meine frage: Wie kann ich auf den Bus senden? Mit einem Logikanalyzer an der Interfaceplatine mit dem Komparator komme ich nicht wirklich weiter weil ich nur 32k Ram habe... Muss ich das ganze noch einmal bauen um auf dem Bus zu sniffen? Oder könnt ihr mir weiterhelfen? LG Floppy
SysRun schrieb: > Hier übrigens "meine" Werte: https://cosm.com/feeds/87491 :) Hast du mal über eine Nachtabsenkung von ein paar Grad nachgedacht? Eine VL-Temp von 63.8°C bei AT 1°C ist meiner Meinung etwas zuviel des Guten, die Heizung kann doch die Pumpe hochmodulieren und dann geht es auch mit etwas weniger Heizleistung. Wie sieht denn dein RL-Temp. aus? Grüße.
Hallo! Ich würde gerne die Heizung in OpenHab einbinden (http://code.google.com/p/openhab/). Hat jemand Interesse, an einem Interface (für Rasberry PI) und an dem nötigen Binding für OpenHab mitzumachen? vg Jürgen
Hallo, ich habe das PIC Gateway von Ingo und nutze ein Python Script um die raw Daten auszulesen. Von Zeit zu Zeit habe ich falsche Werte in meiner DB so das ich gerne die CRC checken würde. Habe hier auch die beiden Python Beispiele von Rudi gefunden, die bei mir so nicht laufen. Das Format müsste ja so aussehen: 0xaa 0x55 <ems data> <ems checksum> <0x00=brk> <length between markers> 0xaa 0x55 Wenn ich versuche die CRC berechnung über die <ems data> zumachen bekomme ich folgende Fehlermeldung:
1 | für crc1(a): |
2 | crc1 = crc1 ^ int(a[i],16) |
3 | ValueError: invalid literal for int() with base 16: '\x08' |
4 | |
5 | bzw. für crc2(a): |
6 | crc1 = crc1^int(a[i]) |
7 | ValueError: invalid literal for int() with base 10: '!' |
Was läuft da falsch?!?
1 | def crc1(a): |
2 | try: |
3 | poly = 12 |
4 | crc1 = 0x00 |
5 | for i in range(0,len(a)-1): |
6 | crc1 = crc1 ^ int(a[i],16) |
7 | crc2 = crc1 |
8 | if crc1 & 0x80: crc1 ^= poly |
9 | d = 0 |
10 | if crc1 & 0x80: d = 1 |
11 | crc1 = crc1 << 1 |
12 | crc1 &= 0xfe |
13 | crc1 |= d |
14 | return crc2 |
15 | |
16 | except Exception, ex: |
17 | logging.exception("crc: Something awful happened!" + str(ex)) |
18 | return "" |
19 | ###################################################################################################
|
20 | |
21 | def crc2(a): |
22 | try: |
23 | crc1 = 0x00 |
24 | for i in range(0,len(a)-1): |
25 | d = 0 |
26 | if crc1 & 0x80: |
27 | crc1^=12 |
28 | d = 1 |
29 | crc1 = crc1 << 1 |
30 | crc1 &= 0xfe |
31 | crc1 |= d |
32 | crc1 = crc1^int(a[i]) |
33 | return crc1 |
34 | ###################################################################################################
|
Gruß Kay
Hallo, Die Prüfsumme wird nur aus den EMS-Daten berechnet. Wenn ich deinen Quelltext richtig verstanden habe nimmst du alle Daten von Index 0 bis-1. Gruß Ingof
Sorry, auf dem Handy hatte ich wohl nicht alles richtig sehen können. Also der Bereich ist ja wohl doch der richtige. Ich würde jetzt einfach mal sagen dass dort irgendwelche Zeichen in HEX oder DEZ umgewandelt werden sollen die nicht als Eingabe akzeptiert werden. Bei der ersten Fehlermeldung würde "\x08" dem Backspace entsprechen und beim zweiten Fehler kann er das Ausrufezeichen nicht in eine Zahl umwandeln. Vermute in A[i] ist ein fehlerhaftes Zeichen. Aber diese Konvertierung benötigst Du doch nicht, oder? Wenn die zeichen als RAW ankommen sind es keine ASCII-Zeichen die mit INT(a[i],16) umgewandelt werden müssen. statt INT(a[i],16 dann einfach a[i] nehmen. Kenne zwar kein Phyton, aber sieht genauso wie JAVA aus... Gruß IngoF
Noch ein paar Schnipsel mit neuen Feldern: ---------------- 10 88 14 00 03 6E 00 07 [ 10 RC35 -> ?88 UBA ] typ=14, off=00, length=03 08 10 14 00 2D 63 EA C1 00 09 [ 08 UBA -> 10 RC35 ] typ=14 Betriebszeit gesamt h 49578.3 (off=1,len=3,div=60) ---------------- 10 88 04 00 10 3D 00 07 [ 10 RC35 -> ?88 UBA ] typ=04, off=00, length=10 08 10 04 00 04 1C 0B 40 0F 25 48 00 00 69 6B 0C 00 00 48 BC 00 15 [ 08 UBA -> 10 RC35 ] typ=04 BCM-Nr. 1052 (off=1,len=2) BCM 11 (off=3,len=1) ----------------- hat sonst noch jemand etwas Neues? vg Jürgen
I have a ServiceKey and would love to do basic on/off, temp changes, monitoring, via a Raspberry PI too :)
Hi Rudi, mit welchem Hardwaremodul hast du die Anbindung an den Pi realisiert? Würdest du auch den Code dazu zur Verfügung stellen? Gruss Norbert
Norbert Schnitzler schrieb: > Hi Rudi, > > mit welchem Hardwaremodul hast du die Anbindung an den Pi realisiert? > Würdest du auch den Code dazu zur Verfügung stellen? > > Gruss > Norbert Ich benutze folgende Hardware: https://www.dustos.org/data/ems_converter_v0_2.png Den PI benutze ich nicht?! Grüße.
Hi Rudi, danke für den Link, hatte mich verlesen, der mit dem Pi war sysrun, ich hätte auch Interesse an einer Anbindung an Openhab, wie jschmied. Gruss Norbert
Hallo! Ich bringe dem EMS-GW im Moment TCP/IP und JSON bei. Damit dürfte sich auch die OpenHAB Anbindung einfach ohne ein spezielles Binding realisieren lassen. Ob ich mir noch einen OpenHAB Server hinstelle, wenn das GW alles selbst macht (incl. WebGUI und Logs schreiben) weiß ich noch nicht. ;) vg Jürgen
Hi Jürgen, ist das der normale oder schon gepimpte Gateway (größerer Pic mein ich irgendwo gelesen zu haben) von Ingo? Gruss Norbert
Hallo! Mit ein paar Web-Seiten ohne JSON bin ich bei 31K ROM und 1366 RAM. Der PIC18F4580 hat 32 KB ROM. Ohne Webseiten würde das JSON Interface warscheinlich reinpassen. Es wäre (zumindest für mich) aber einfacher den PIC zu wechseln, als X Versionen der Firmware zu pflegen. In die 96KB des PIC18F4685 passt alles rein. Ich habe ein Board (wg. Blitzschaden) bereits umgebaut, den PIC zu wechseln geht schnell. Ich habe den alten mit einem Dremel weggefräßt, um das Board nicht zu beschädigen ;). Dann kann man die Reste der Beinchen einzeln auslöten. vg Jürgen
Du kannst bist auf die index.html alles auf einem Webserver auslagern. Dann fragst du nur direkt die Werte ab und die restlichen Seiten änderst du auf dem Webserver.
Hallo! Ja, man kann alles auf einen externen Websserver packen und das GW nur JSON sprechen lassen. Da muss dann jeder für sich einen Webserver einrichten und die URL auf das GW konfigurieren. Nachteil: Es ist dann ein extra Gerät oder Webspace im Internet nötig Vorteil: Man kann leicht erweitern, andere Geräte einbinden, Design ändern, Grafik einbinden usw. vg Jürgen
Hallo, an alle die einen EMS-Gateway oder eine andere Hardware für den EMS-Bus haben: Es gibt jetzt eine Wiki zum EMS-Gateway (nicht Logamatic 2107): http://ems-gateway.myds.me:8001/dokuwiki/ Es kann so gut wie alles gelesen werden. Nur zum lesen einiger Bereiche (Telegramme des EMS-Bus) wird eine Registrierung benötigt. Um Mithilfe bei der Entschlüsselung der EMS-Telegramme wird gebeten. Da in diesem Thread auch der EMS-Gateway entstanden ist poste ich es auch hier... Gruß IngoF
Ingo F. schrieb: > Es gibt jetzt eine Wiki zum EMS-Gateway (nicht Logamatic 2107): > http://ems-gateway.myds.me:8001/dokuwiki/ > > Es kann so gut wie alles gelesen werden. > Nur zum lesen einiger Bereiche (Telegramme des EMS-Bus) wird eine > Registrierung benötigt. > > Um Mithilfe bei der Entschlüsselung der EMS-Telegramme wird gebeten. Vielleicht bin ich einfach zu blind, aber: Wie meldet man sich an? Eine Registrierungsseite habe ich nicht gefunden... (Davon mal abgesehen: Warum der Registrierungszwang für die EMS-Telegramme?)
Danny Baumann schrieb: > aber: Wie meldet man sich an? Ganz einfach... oben rechts auf registrieren ;-) Aber lag nicht daran dass Du blind warst.. Habe wohl zuviel an der Konfiguration herumgespielt. Und schwups war die Registrierung futsch... Gruß Ingo
So der Winter naht wieder... und ich habe dass Geraffel wieder hervor geholt. Nach längerem durchforsten der EMS Protocol Plugin Codes von Ethersex habe ich es nun auf einem ATMega 644P (wieder) laufen. Dazu musste in der ems_uart.h folgendes hinzugefügt werden: #define PORTEMS_UART_TX_PORT PORTD #define EMS_UART_TX_PIN PIND #define DDREMS_UART_TX_PORT DDRD Nun haut das Netio auch per TCP/IP die Daten raus. Mit Wireshark habe ich mal reingeschaut, wobei man ja nicht all zu viel sieht. Wie wertet ihr die Daten aus? (Ich hatte ja mal was laufen, kann mich aber zum Teufel nicht mehr erninnern wie/was). Weiterhin gibt http://192.168.0.90/ecmd?ems%20stats folgendes aus: Bytes total:37301 Bytes good:528 Bytes dropped:0 Packets good:83 Packets bad:1959 Packets 1byte:25524 501 Packets ack:0 nack:0 Overflow:0 Max fill:2 Könnt Ihr mir weiterhelfen? LG Floppy Tante Edit: So, habe noch Realterm probiert und inerhalb von so ca. 5 Minuten folgendes mitgelogt: AA 55 05 08 13 05 22 00 3C AA 55 06 17 08 35 00 11 11 2A AA 55 08 17 08 1A 00 00 00 00 00 05 AA 55 05 17 00 AD 03 01 B8 AA 55 02 17 FC EB AA 55 05 08 13 05 22 00 3C AA 55 05 08 13 05 22 00 3C AA 55 06 17 08 35 00 11 11 2A AA 55 08 17 08 1A 00 00 00 00 00 05 AA 55 05 08 13 05 22 00 3C AA 55 05 08 13 05 22 00 3C AA 55 15 08 00 34 00 28 00 D6 80 00 80 00 04 01 00 00 15 BC 00 30 B7 00 E9 AA 55 02 17 FC EB AA 55 05 08 13 05 22 00 3C AA 55 15 08 00 34 00 28 00 D4 80 00 80 00 04 01 00 00 15 BC 00 30 B7 00 EB
Such mal in meinen Postings in diesem Thread nach ems-collector ... das ist die Gegenseite dazu, die die von ethersex gelieferten Daten auswerten und in eine mysql-Datenbank schreiben kann.
Hallo, ja daran habe ich mich auch schon versucht. Das ganze habe ich nach ein paar installierten Dev-Libs auf einer Debian Kiste kompiliert bekommen. Nun klemmts am Aufruf... Mysql Username und Datenbank sind erstellt, aber ich bekomme weiterhin fehlermeldungen dass das Device nicht gültig ist. gibt es hiezu Doku? Bis auf die kleine Help Ausgabe habe ich im Dunkeln gestochert und mich an Fehlermeldungen entlang gehangelt. ./collectord -u ems -p xxx -d5 -f 192.168.0.90 Exception: Target 192.168.0.90 is invalid. LG
./collectord -u ems -p pass -d all -f tcp:192.168.0.90:7100 sollte funktionieren (evtl. must du den Port anpassen). Dass die Hilfe für das Target nicht angezeigt wird, ist eine Limitierung in boost::program_options (oder meiner Unfähigkeit geschuldet, das Zeug richtig zu benutzen).
Nun kommt was :) Danke schonmal ./collectord -u ems -p ems -d all -f tcp:192.168.0.90:7950 IO: Got bytes 0xaa 0x55 0x5 0x8 0x13 0x5 0x22 00 0x3c MESSAGE[14.09.2013 09:58:39]: source 0x08, dest 0x13, type 0x05, data 0x22 0x00 DATA: Unhandled message received(source 0x08, type 0x05). IO: Got bytes 0xaa 0x55 0x2 0xb8 0xfe 0x46 MESSAGE[14.09.2013 09:58:41]: source 0x00, dest 0x00, type 0x00, data 0xb8 0xfe IO: Got bytes 0xaa 0x55 0x5 0x8 0x13 0x5 0x22 00 0x3c MESSAGE[14.09.2013 09:58:59]: source 0x08, dest 0x13, type 0x05, data 0x22 0x00 DATA: Unhandled message received(source 0x08, type 0x05). Nun müsste man nur noch was damit anfangen können. Wie kann ich nun aktiv eingreifen? Ich will im endefekt von Tag auf Nacht umschalten können. Wie stelle ich das Webinterface ein dass es daten anzeigt? LG Tante Edit: so die Website liefert ein Bild nachdem ich username/password angepasst habe (in sensor_utils.php.inc), wobei mit total wirren Informationen... da passt garnichts
Tag/Nacht umstellen sollte damit gehen: telnet localhost 7777 hk1 mode night (oder hk2 mode auto, oder...) Die Webseite ist mehr oder weniger ein Quick Hack, da musst du im Zweifelsfall mal etwas frickeln. Stimmen denn die Werte in der Log-Ausgabe und/oder der Datenbank?
Ich habe mal bis hk4 durchprobiert... kommt immer ERRTIMEOUT :( Die datenbank füllt sich auch kaum... kann es sein dass ich irgendwo zuordnungstabellen anpassen muss? Es ist halt leider ein RC25 und kein RC35 Panel.
Bei ERRTIMEOUT hat sich die RC nicht angesprochen gefühlt ... bei den Unterschieden zwischen RC25, RC30 und RC35 bin ich allerdings überfragt. Selbst habe ich ein RC30, damit funktioniert es. Zwei Dinge kommen mir aber komisch vor: der Bus-Slave 0x17 (ist das die RC25?) und die sehr hohe Anzahl an Bad packets, d.h. CRC-Fehlern. Letzteres deutet darauf hin, dass an der Schaltung noch etwas nicht in Ordnung ist. Bei mir ist das Verhältnis good-bad z.B. im Moment 817000-24.
Hmmmm okay.... aber die Kesselsolltemperatur stimmt schonmal. 40°C sind an der Heizung eingestellt (durchlauferhitzer). Wie komme ich dem ganzen am besten bei? So etwas zu Debuggen ist ja nicht gerade trivial.
So, ich war noch ein paar Daten sammeln ;) Heizung: Buderus U154-20k Bedieneinheit: RC25 Daten in dem RC25: P1 -> 0 (Master ohne weitere Programmiergeräte) P2 -> 1 (Roomflow Mode / Regelkreis auf die Durchflussrate) P3 -> 0.0°C (Raumkalibrierung) P4 -> 1 (DHW Heating True) P5 -> 1 (Internal Boiler Pump) P6 -> 5 (Nachlaufzeit Boiler Pump) P8 -> 0 (Time Adjustment) P9 -> 0 (No thermal disinfection) P10-> 401 (Software Version) P13-> 75°C (Maximum Flow Temperature) Vllt. hilfts ;) Mensch wär ich happy wenn ich irgendwie die f**k Heizung per TCP/IP ein/aus schalten kann. Geht sowas überhaupt? Es kann ja auch sein dass der RC25 als 2-Punkt Regler funktioniert und nur Brenner ein/aus Kommandos gibt. Somit wäre die komplette Steuerung in dem RC25 und der Zustand Auto/Sonne/Mond kommt nie über den Bus und ist somit auch nicht beeinflussbar... (ANGST :p) Da das Modul nicht mir ist (Mietshaus) würde ich Ungern direkt auf die Taster gehen (wobei ich immer mehr dazu tendiere). LG :)
Das kennst Du? http://www.buderusdaten.ch/webseite/joomla/index.php?option=com_remository&Itemid=38&func=fileinfo&id=1814 Auf alle Fälle muss die RC25 dem UBA (Brenner) regelmäßig bestimmte Pakete senden, ansonsten schaltet sich die Heizung nach einer Weile ab. Da die UBA bestimmt nur ein Protokoll spricht, sind es bestimmt die gleichen Pakete wie auch die RC35 senden würde. Hat jemand mit einem EMS-GW einen RC25 als Master und kann einen Busmitschitt machen? Am besten incl. Boot-Sequenz dre Anlage. vg Jürgen
Angehängte Dateien:
-
ems.png
22 KB
Ja das Dokument hab ich in Englisch per Google gefunden ;) Aber deutsch ist mir auch lieber. Also muss ich nun als nächstes erst mal das bad/good Verhältniss aufpeppeln? Nur wie? Ich flashe gleich mal eine erweiterte Debug Software in das NetIO. Werde dann auch gleich mal den Schaltplan des Adapter-Moduls heraussuchen und hochladen. Tante Edit: So nun mit Schaltplan. das Adapterkabel schaut wie folgt aus: EMS Board - EXT Netio 1 (VCC) - 10 (5V) 2 (RX Out)- 1 (PD2) 3 (TX in) - 2 (PD3) 4 (U Ref) - NC 5 (GND) - 9 (GND)
Hallo! Prüfe mal die Taktfrequenz des Mikrocontrollers und die Baudrate der UART. Ein Fehler dort bring alles durcheinander. Kritisch sind eigentlich nur C3/R4, da deren Zeitkonstanate nahe an der Baudrate ist, wirken sich Änderungen der Teile direkt auf die Tastverhältnisse an der UART aus. Der + des OPV müsse ca. 0,6 V haben, der - ungefähr 0,05 V weniger. Ansonsten ist an der Schaltung nicht viel falsch zu machen ... vg Jürgen
@Ra Sp
> [Schaltplan]
U_REF hast du falsch gedeutet. Hättest du nicht herausführen müssen, ist
ne' rein interne Angelegenheit.
//Niffko
Ra Sp schrieb: > Heizung: Buderus U154-20k Der U154 ist, wenn man's genau nimmt, mehr Junkers als Buderus (Bosch-Synergieeffekt). Die Steuerplatine wird auch nicht als UBA bezeichnet. Kann was bedeuten, muss aber nicht. Auf jeden Fall könnte es Unterschiede geben. //Niffko
Ja ist herausgeführt um evtl. mal zu erkennen ob der Bus angeschlossen ist. Man weis ja nie :) Wie prüfe ich bei RX die Baudrate? ;) LG
Ra Sp schrieb: > [U_REF] > Ja ist herausgeführt um evtl. mal zu erkennen ob der Bus angeschlossen > ist. [ironie] Achso ... dafür sind die ~0,6V natürlich geradezu ideal. [/ironie] ... nicht bös' gemeint ;) //Niffko
niffko schrieb: > [ironie] > Achso ... dafür sind die ~0,6V natürlich geradezu ideal. > [/ironie] Tjoa... um ganze Bytefolgen zu übertragen reichts ja wohl.... dann werde ich wohl auch ein Bit heraus bekommen. Wo ein Wille da ein Gebüsch oder so :p Wenns denn nötig wäre könnte man auf einen ADC Eingang gehen (für was anderes sind die AVR ADCs eh nicht zu gebrauchen) LG
Angehängte Dateien:
-
EMS_Burst3.jpg
5,4 MB -
EMS_Burst2.jpg
5,4 MB
Es gibt Neues... Auch wenn es nur ein Bild ist :p Messaufbau: Grün: EMS - High side Gelb: RX Out der Adapterplatine Masse hole ich am Steckverbinder NetIO-Adapterplatine Nur woher kommen die Drifts? Denke das sind meine Kommunikationsprobleme.
Nein, das ist völlig normal. Wenn man sendet wird nur das kleine Signal auf dem Bus erzeugt. Dannach wird das gesendete Byte vom Busmaster (0x08) widerholt. Erst dannach kann das nächste Byte gesndet werden. Also nach jedem gesendeten Byte mindestens ein Byte abwarten.. Bild 2 ist also voll OK. Nur das erste Bild sieht seltsam aus. Ist das bei jedem Sendeversuch so? Gruß Ingo
naja Sendeversuch ist meinerseits nie gelaufen. Das ist ein Mitschnitt zwischen Heizung und RC25. Und es sieht relativ häufig so aus.
IngoF schrieb: > Nein, das ist völlig normal. war vermutlich zu schnell beim lesen und schreiben.... Es ging um den Drift in Bild1 oder? Das sihet nicht so gut aus. Ist das schon auf dem Bus wenn Deine paltine nicht angeschlossen ist? Gruß IngoF
Hmm... die Datenübertragung ohne NetIO schaut gut aus. Diese Ausläufer treten ohne Platine nicht mehr auf. Ob ich das Notebook beim Messen einstecke oder nicht ändert daran wohl nichts. Nun ist die Frage wo ich sonst die Masseschleife her bekomme (ich gehe nun einfach mal davon aus). Evtl übers Ethernet?! Probiere ich gleich noch einmal aus.
So, hole ich mir nun die Masse vom Bus, driftet das gelbe Logiksignal umher. Zwischen beiden Massen liegt ja eigentl. nur eine Diode. Klemme ich Ethernet ab, sind die Drifts weg.Nun kann ich leider die Sache nicht mehr debuggen. Tante Edit: Der RS232 Ausgabe entnehme ich dass es wohl geht. Die CRC stimmt mit der berechneten über ein.. Ich bekomme im Sekundentakt Meldungen folgender Art: D: ems: No client connected, dropping 5 bytes D: ems: Packet CRC a2 calc a2 Nun muss ich zusehen wie ich die Masseschleife unterbinde.
:
Bearbeitet durch User
Hallo! Bei mir ist der EMS Bus an der Therme geerdet. Wenn der Oszi auch eine Masse mitbringt, gibts Probleme ... vg Jürgen
Ra Sp schrieb: > Der RS232 Ausgabe entnehme ich dass es wohl geht. > Die CRC stimmt mit der berechneten über ein.. Ich bekomme im > Sekundentakt Meldungen folgender Art: > > D: ems: No client connected, dropping 5 bytes > D: ems: Packet CRC a2 calc a2 Ja, ds sieht gut aus. Das 'dropping X bytes' passiert ja nur, weil er die Daten nirgendwo hin weiterleiten kann. > Nun muss ich zusehen wie ich die Masseschleife unterbinde. Hmm. Hast du an deinem NetIO schon irgendeine Modifikation durchgeführt? Ich musste eine ganze Menge Elkos um den ENC28J60 verteilen, damit der langzeitstabil wurde und sich nicht nach einer Woche oder so weggehängt hat (Anleitungen dazu findet man im Netz). Ich meine, mich dunkel erinnern zu können (ist ja schon 1,5 Jahre her), dass ich in diesem Zuge auch die Masse der Ethernet-Buchse des NetIO galvanisch getrennt habe: Lotflächen für die Schirmung von der entsprechenden GND-Plane getrennt (mit einem Cuttermesser weggeritzt) und mit einem C wieder verbunden. Das dürfte bei dir dann wahrscheinlich auch helfen. Warum Pollin da nicht selbst drauf gekommen ist, weiß aber kein Mensch...
Angehängte Dateien:
-
EMS_Send.jpg
5,4 MB -
EMS_hk1night.jpg
5,4 MB
So... nun geht es sogar mit Ethernet :p Bytes total:93010 Bytes good:20370 Bytes dropped:0 Packets good:1058 Packets bad:3 Packets 1byte:71628 1377 Packets ack:0 nack:0 Overflow:0 Max fill:6 Das schaut ja soweit gut aus. Nun bleiben noch folgende Punkte offen: 1.) Tag/Nacht umschalten 2.) Tag/Nacht auslesen 3.) evtl. Raumtemperatur auslesen (eher unwichtig) Ich versuche gleich erstmal den TX am µC aufzuzeichnen. Kann ich direkt (per ecmd oder ähnlich) Hex-Bytes versenden? LG Tante Edit: Also das hk1 mode night kommando erzeugt das zweite Bild (gelb RX, grün bus), und dann kommen noch im x Sek Takt die Signale aus Bild 1. Aufgrund falscher Bilder habe ich den letzten Beitrag gelöscht
Bitte beachte die Bildformate! Und Bitmaps als JPG abzuspeichern macht kein Sinn. Mit z.B. IrfanView hats soetwas schnell als png abgespeichert(geht sogar auch mit MS Paint)
Uh... sorry. Nun sehe ich es auch. Das macht die billige Hantech Software. Dort kann ich zwar zwischen JPG und BMP wählen, was aber wohl nicht implementiert ist. Dann verwende ich ab jetzt das Snippingtool von Windows.
Ra Sp schrieb: > Ich versuche gleich erstmal den TX am µC aufzuzeichnen. Wenn du mal ein git pull im ems-collector machst, siehst du danach die gesendeten Bytes direkt in dessen Debugausgabe ;) > Kann ich direkt (per ecmd oder ähnlich) Hex-Bytes versenden? Nein. Ich hab mir für solche Zwecke immer schnell den collector gehackt. Es wäre aber in der Tat wahrscheinlich mal eine sinnvolle Idee. > Also das hk1 mode night kommando erzeugt das zweite Bild (gelb RX, grün > bus), und dann kommen noch im x Sek Takt die Signale aus Bild 1. Ich glaube, vom elektrischen Debugging kannst du jetzt weggehen. Was sagt den die Debugausgabe von ems-collector, wie sehen die empfangenen Pakete zu diesem Zeitpunkt (dekodiert) aus?
So, heute erstmal den tftp-Kram vorbereitet. Morgen verfrachte ich das Teil mal an die Heizung. Kann mir jemand Service Unterlagen geben? Finde nix zur U154-20k LG
So, habe jetzt genug an der Wiki rumgefummelt. Jetzt hat sich zum letzten mal die Adresse geändert. Der Port (:8001) kann und muss jetzt weggelassen werden. Neue Adresse: http://ems-gateway.myds.me/dokuwiki/ Sonst hat sich auch noch was geändert: Unregistrierte Benutzer können jetzt auch alles lesen. Registrierte Benutzer können jetzt per Mail bei Änderungen informiert werden. Gruß IngoF
IngoF schrieb: > habe jetzt genug an der Wiki rumgefummelt. Sieht doch gut aus ... zum Glück kann man wenigstens alles lesen. Hat zufällig jemand ein Zeitmodul am laufen und ein Log vom EMS-Format? Dann könnte man direkt die immer wieder falsch laufende RC synchronisieren. ---
Die Firmware für das neue Board soll das können, sie besorgt sich per NTP die genaue Zeit. Ich habs noch nicht probiert, aber ich denke: 0B 10 06.00 0D 09 14 13 00 00 <CRC> ............YY.mm.hh.dd.mi.ss sollte die Zeit auf den 13.09.2013 20:00 setzen. PS: Wir sollten mal einen neuen Thread auf machen. Mein UMTS Datenkontigent ist sonst mit 3 Mal hier rein gucken alle ;) vg Jürgen
:
Bearbeitet durch User
Jürgen Schmied schrieb: > Wir sollten mal einen neuen Thread auf machen. ^^finde ich gut. Ich lese schon lange den Thread mit. Mit meiner langsamen DSL-Verbindung dauert es ewig das sich die Seite öffnet. Gibt es eine Möglichkeit nur die letzten Texte zu lesen?
Hi, habe nun den collector angepasst und logge alle Rohdaten inkl. Timestamp. Heute Abend gibts das File :-)
############################################################# *** Bitte hier nicht mehr posten *** ... wegen Überlänge ... Bitte hier weiter machen: Beitrag "Faktensammlung Buderus EMS" #############################################################
:
Bearbeitet durch User
Hallo zusammen, habe bereits das NetIo-Board zusammengelötet. Wollte statt dem 644p den 1284p einsetzen. Wollte mir dann das Ethersex-File für den Atmega zusammenstellen. Allerdings kann ich das EMS-Protokoll nicht auswählen. Bei kommt immer die Meldung "EMS not available. No free USART. (0/0)" - egal, ob ich als CPU den 644p oder den 1284p auswähle. Hat jemand einen Tipp, was ich falsch mache? Vielen herzlichen Dank schon mal im Voraus!
Andreas S. schrieb: > Allerdings kann ich das EMS-Protokoll nicht auswählen. > Bei kommt immer die Meldung "EMS not available. No free USART. (0/0)" - > egal, ob ich als CPU den 644p oder den 1284p auswähle. > > Hat jemand einen Tipp, was ich falsch mache? Ja - du brauchst einen 644PA. Das A ist entscheidend, denn nur der A hat eine 2. UART.
Danny B. schrieb: > Andreas S. schrieb: >> Allerdings kann ich das EMS-Protokoll nicht auswählen. >> Bei kommt immer die Meldung "EMS not available. No free USART. (0/0)" - >> egal, ob ich als CPU den 644p oder den 1284p auswähle. >> >> Hat jemand einen Tipp, was ich falsch mache? > > Ja - du brauchst einen 644PA. Das A ist entscheidend, denn nur der A hat > eine 2. UART. Ich hab nur den Atmega644 sowie 644p zur Auswahl im ethersex. Wie bringe ich den Atmega 644pa in die Liste rein?
Andreas S. schrieb: > Danny B. schrieb: >> >> Ja - du brauchst einen 644PA. Das A ist entscheidend, denn nur der A hat >> eine 2. UART. > > Ich hab nur den Atmega644 sowie 644p zur Auswahl im ethersex. Wie bringe > ich den Atmega 644pa in die Liste rein? Mea culpa. Ich nehme alles zurück; der 644p sollte gehen. Die 2. UART ist der Unterschied zwischen 644 und 644p, nicht zwischen 644p und 644pa. Bei mir geht aber die Konfugiuration auch mit dem 644p: Load a default configuration -> NetIO, dann den 644p auswählen, dann unter Protocols -> EMS anschalten und '1' als 'EMS USART' auswählen. Wie genau gehst du bei der Konfiguration vor?
Danny B. schrieb: > Andreas S. schrieb: >> Danny B. schrieb: >>> >>> Ja - du brauchst einen 644PA. Das A ist entscheidend, denn nur der A hat >>> eine 2. UART. >> >> Ich hab nur den Atmega644 sowie 644p zur Auswahl im ethersex. Wie bringe >> ich den Atmega 644pa in die Liste rein? > > Mea culpa. Ich nehme alles zurück; der 644p sollte gehen. Die 2. UART > ist der Unterschied zwischen 644 und 644p, nicht zwischen 644p und > 644pa. > > Bei mir geht aber die Konfugiuration auch mit dem 644p: Load a default > configuration -> NetIO, dann den 644p auswählen, dann unter Protocols -> > EMS anschalten und '1' als 'EMS USART' auswählen. > > Wie genau gehst du bei der Konfiguration vor? Hallo Danny, ich habe mir unter CentOS 7 die benötigten Pakete heruntergeladen. Anschließend habe ich das gitlab-Archiv auf meinen Rechner kopiert. Anschließend mit make menuconfig gestartet Dort dann Load a default configuration -> NetIO und als CPU den Atmega 644p ausgewählt. Wollte dann unter Protocols das EMS anschalten, jedoch erhalte ich die besagte Fehlermeldung, das kein UART frei ist. Ich könnte mir höchstens vorstellen, das es am OS liegt (CentOS 7)
:
Bearbeitet durch User
Hallo Danny, Entwarnung, habs jetzt mal auf meinem Firmennotebook ausgeführt (ebenfalls CentOS 7) Hier funktionierts jetzt. Komisch, das es dann auf meinem Werkstatt-PC nicht funktioniert hat. Vielen herzlichen Dank für deine Unterstützung!
Konnte jetzt alle bis auf eine Einstellung von https://emswiki.thefischer.net/doku.php?id=wiki:ems:net_io vornehmen. Das Feld "[-] Onewire device detection support" kann ich leider nicht auswählen. Hängt dies evtl. von einer Einstellung ab, die Standardmäßig vielleicht ausgewählt ist? Hast du hier für mich zufällig noch einen kleinen Tipp?
Andreas S. schrieb: > Konnte jetzt alle bis auf eine Einstellung von > https://emswiki.thefischer.net/doku.php?id=wiki:ems:net_io vornehmen. > > Das Feld "[-] Onewire device detection support" kann ich leider nicht > auswählen. Hängt dies evtl. von einer Einstellung ab, die Standardmäßig > vielleicht ausgewählt ist? > > Hast du hier für mich zufällig noch einen kleinen Tipp? Nach langem Testen und probieren habe ich jetzt den Blockierer gefunden: Wenn ich Debugging aktiviere "[*] Enable Debugging --->" dann kann ich die Option auswählen. Dieser Punkt hatte im Wiki leider gefehlt.
Hallo, gibt es von der KM271 einen "erfolgreichen" Nachbau? Chipshuffler hat einen Schaltplan veröffentlicht: Beitrag "Re: Logamatic 2107 Schnittstelle" Die RS232 Schnittstelle ist dort ja nicht das Problem. Ansonsten würde ich mich daran machen... Malte war hier auch aktiv, hat seine Versuche zwar in seinem Wiki gepostet, ist leider aber nicht mehr online. Wer hier noch Daten hat kann mir gerne zukommen lassen.
Angehängte Dateien:
-
connector-front.png
17 KB -
connector-back.png
18 KB -
platine.jpg
230 KB
Hallo, ich habe aus allen verfügbaren Informationen aus diesem Forum einen Adapter entwickelt, der die Steuerung der Heizung über eine serielle Schnittstelle ermöglicht. Alles natürlich auf eigene Gefahr nachmachen. Der Adapter ist simpel. 5V, GND, RX und TX stehen als Lötkontakt zur Verfügung und können mit einem USB-Serial-Wandler verbunden werden. Ein 10k Widerstand sorgt dafür, dass das Modul erkannt wird. Es erscheint dann der zusätzliche Menüpunkt Abgastemperatur ohne Wert im Display. Die Seite die mit Front beschriftet ist muss zum Display zeigen. Die Beschriftung habe ich nachträglich eingefügt, deshalb fehlt sie auf dem Foto. Bilder und die CAM-Datei findet ihr im Anhang. Eine dauerhafte Lösung zum Auslesen und Steuern habe ich noch nicht entwickelt. Ich nutze einen Raspberry-Pi und die Python-Skripts vom Nutzer Black aus folgendem Thread: https://homematic-forum.de/forum/viewtopic.php?t=26955 Ich kann die Werte erfolgreich auslesen und auch erfolgreich Werte setzen. Es mangelt allerdings noch an der Stabilität und eigentlich würde ich das ganze auch mithilfe eines ESP8266 bzw. ESP32 lösen.
Kann man die Platinen denn erwerben? Da könnte ich meine alte Heizung doch noch an den Pi bringen :-D
Hi zusammen, Ich hätte ebenfalls Interesse an einem Adapter. Gibt es noch irgendwelche Aktivitäten? Viele Grüße und danke
Es wurden doch Fertigungsdaten gepostet, mit diesen wendet man sich an den Chinamann seines vertrauens und bekommt für wenige Euronen fertige Platinen.
Ja, ja. Platinen machen lassen... Ich habe da auch keine Erfahrung. Hat jemand eine zu verkaufen? Nackt/bestückt/ wie auch immer? Danke & Gruß
Hi, ich hab mir die Platine erstellen lassen - war kein Hexenwerk. Ich bin aus Zeitgründen noch nicht dazu gekommen weiter zu machen :-( Eine Frage in die Runde: Hat sich schon jemand an die Umsetzung mittels ESP8266 gemacht? Ich habe mir damals zwei Platinen machen lassen und eine liegt hier noch rum (ohne Wiederstand). Viele Grüße
Jens K. schrieb: > Hi, > ich hab mir die Platine erstellen lassen - war kein Hexenwerk. Ich bin > aus Zeitgründen noch nicht dazu gekommen weiter zu machen :-( > Eine Frage in die Runde: Hat sich schon jemand an die Umsetzung mittels > ESP8266 gemacht? > > Ich habe mir damals zwei Platinen machen lassen und eine liegt hier noch > rum (ohne Wiederstand). > > Viele Grüße Hallo Jens, nach was muss ich googlen zum Erstellen der Platinen? Bisher scheitere ich daran, die Daten aus dem ZIP bei gängigen Platinenherstellern einlesen zu lassen. Also wie finde ich den ChinaMann? Gruß Ingo
Angehängte Dateien:
-
Buderus_2701_Display.jpg
120 KB
Hallo Jens. Weil nach 20 Jahren das Display streikt (s. Bild), bin ich via Google hier gelandet - weil ich die Systemzeit nicht mehr einstellen bzw. ablesen kann. Wie du beschreibst, kannst du erfolgreich Werte schreiben. Hast du evtl. herausgefunden, ob/wie man die Systemzeit über die Schnittstelle setzen kann?
Ich habe mir die Platine hier bestellt: https://bbqkees-electronics.nl/?lang=de Preis finde ich ok - es gibt sogar ein komplettpaket mit ESP8266 und der EMS-ESP software Nutze die jetzt seit monaten zusammen mit einem ESP8266 und MQTT
Moin, hat schon jemand eine Lösung um die Raumtemperatur via Funk (WLAN) zur Heizungsanlage bzw. RC300 zu transportieren? Ggf. via zwei ESP8266 als Kabelersatz? Folgendes Problem: ich kann kein Kabel verlegen, möchte aber neben der Außentemperaturregelung auch die Raumtemperatur als Regelgröße nutzen. Grüße Peter
Hallo und Frage an die Spezialisten: Im Schaltplan der 2107 gibt es einen Anschluss 230V Signal Brenner: Betrieb BR 8/B4 und Störung BR 9/S3 sowie 4/N (Nulleiter). Kann ich dort parallel ein 230V monostabiles Relais(Finder 13.31.8.230.4300) zum potentialfreien Schalten eines WIFI Aktors (Sonoff MiniR2) anschließen, der mir dann eine Pushnachricht in die App schickt. Das funktioniert (getestet) am heimischen Bewegungsmelder. Bin aber unsicher, ob das BR Signal genug Leistung zum Schalten des Relais bringt. Im Schaltplan wird an der Stelle Brenneranschluß Stufe 1 max.8A angegeben, was vielleicht reichen dürfte??
Hallo, ich weiß, der Thread ist ein wenig älter, aber ich habe noch eine Logamatic, die ich noch eine Zeit lang betreiben muss und brauche dringend den Zugang über die serielle Schnittstelle, weil mein Brenner häufig auf Störung geht (Flammwächter spinnt manchmal) und ich nicht jede Woche kalt duschen möchte. Deswegen habe ich mir ein paar aus diesem Thread zusammengesucht und die KM217 mit WiFi/Bluetooth-Anbindung nachentwickelt und werde diese in den nächsten Wochen auch mit ESPhome und Home Assistant realisieren. Genauere Infos gibt es hier: https://the78mole.de/reverse-engineering-the-buderus-km217/ Wer ebenfalls eine haben möchte, kann mich gerne kontaktieren. Ich werde ein paar PCBs mehr bestellen und zum Selbstkostenpreis (ich schätze ca. 2-3 € pro PCB) abgeben. Grüße, Daniel
Angehängte Dateien:
-
buderus.png
350 KB
Fred G. schrieb: > Ich habe mir die Platine hier bestellt: > https://bbqkees-electronics.nl/?lang=de > > Preis finde ich ok - es gibt sogar ein komplettpaket mit ESP8266 und der > EMS-ESP software > > Nutze die jetzt seit monaten zusammen mit einem ESP8266 und MQTT Ich hab mich grad auf der Seite umgesehen, das ist echt interessant und ich würde mir das Modul mit WLAN gern zulegen. Wie krieg ich raus, ob meine Steuerung damit kompatibel ist, sprich diese Bus-Schnittstelle hat? Weiß jemand von euch das anhand des Fotos? Gruß - Markus
Beitrag #6772582 wurde vom Autor gelöscht.
Angehängte Dateien:
-
buderus.jpg
260 KB -
2.jpg
300 KB
So siehts im Inneren aus, leider nix von einem BUS Anschluss zu sehen 😒 Was meint ihr? Am Typenschild steht HS2105M S0
:
Bearbeitet durch User
Beitrag #6772642 wurde vom Autor gelöscht.
Angehängte Dateien:
-
Logamatic_KM217-Schnittstelle.PNG
1,5 MB -
Bild_Marcus.PNG
580 KB
Hallo Marcus, eigentlich solltest Du im Beitrag auf meinem Blog sehr schön die Schnittstelle erkennen, die es für das KM217 benötigt (siehe auch Bild anbei). Der andere Anschluss sieht zwar identisch aus, aber da ist 1. nicht genug Platz und 2. weiß ich nicht, ob die Belegung die Gleiche ist. Auf Deinem Bild ist die Schnittstelle auch zu erkennen, aber ob das die gleichen Abmessungen und die gleiche Belegung hat, weiß ich natürlich nicht. Grüße, Daniel
:
Bearbeitet durch User
Daniel G. schrieb: > Hallo Marcus, > > eigentlich solltest Du im Beitrag auf meinem Blog sehr schön die > Schnittstelle erkennen, die es für das KM217 benötigt (siehe auch Bild > anbei). Der andere Anschluss sieht zwar identisch aus, aber da ist 1. > nicht genug Platz und 2. weiß ich nicht, ob die Belegung die Gleiche > ist. > > Auf Deinem Bild ist die Schnittstelle auch zu erkennen, aber ob das die > gleichen Abmessungen und die gleiche Belegung hat, weiß ich natürlich > nicht. > > Grüße, > Daniel Hallo Daniel, vielen Dank dir für die Erläuterung. Ich dachte, dass ich mit der fertigen Lösung von dem Online Shop eventuell auch arbeiten könnte. Aber da ich die Schnittstelle nicht habe, brauche ich deine Lösung um Zugriff auf die Daten zu bekommen, soweit ist mir das jetzt klar 👍 Ich hatte dir auch schon eine Email geschrieben, dass ich Interesse an der Platine von dir habe. Ich nehm auf jeden Fall eine! Gruß - Markus
Hi Markus, die Platinen werden gerade produziert und werden vermutlich in ca. 2 Wochen (wenn der Zoll nicht verlängerte Mittagspause macht) bei mir aufschlagen. Hast Du denn die passenden Bauteile alle da, um die Platine zu bestücken? Die BOM findest Du hier: https://gitlab.com/the78mole/logamatic_2107_wifi_comm/-/blob/main/KM217-WiFi/bom/KM217-WiFi.csv Grüße, Daniel
Hi Daniel, perfekt! Meld dich einfach wenn du die Platinen hast dann können wir uns wegen Versand und Zahlung austauschen. Hab nur den EPS32 lagernd 😉 hab bisher maximal SMD 0805 gelötet. Die Sachen muss ich also noch besorgen, irgendwie alles komplett bei einem Anbieter bestellen geht vermutlich nicht oder? Gruß - Markus
Hallo Markus, das Hühnerfutter für den Minimalausbau kann ich Dir noch dazu legen. Die MOSFETs (Level-Shifter) sind hoffentlich garnicht nicht nötig und das EEPROM ist ja auch nur da, falls man lokal was speichern möchte... Falls Du Dir ein kleines Sortiment zulegen willst, ich hab vor vielen Jahren mit den Family-Packs von CSD (https://csd-electronics.de/Passive-Bauteile/Widerstaende/FamilyPacks:::10_57_181.html) angefangen, weil ich schon ein modulares, erweiterbares Sortiersystem hatte und diesen Röhrchenkram immer gehasst habe. Grüße, Daniel
Hi Daniel, das wär natürlich perfekt! Lokal speichern will ich in der Tat nicht, EEPROM brauch ich also nicht. Pack die Sachen dazu und ich bezahl die natürlich auch! Bei CSD schau ich mich mal um, da find ich mir bestimmt was 😉 Danke schon mal vorab, hoffentlich kommen die Platinen dann bald... Gruß - Markus
Hallo Daniel, falls du noch eine Platine über hast, wäre ich auch an einer interessiert - ebenso an dem "Hühnerfutter" :-) Viele Grüße Jens
Hallo, die Platinen sind da und ich hab auch schon eine auf- und eingebaut. Spannungsversorgung passt, LEDs kann ich mittels HomeMatic und ESPhome ein- und ausschalten. Firmware-Update über OTA funktioniert ebenfalls einwandfrei. Jetzt fehlt NUR NOCH die Software, um die serielle Schnittstelle in Betrieb zu nehmen, die Buderus-Steuerung zum Reden zu bringen und die Daten zu dekodieren :-P Den Blog-Post habe ich auch nochmal für alle Interssierten aktualisiert: https://the78mole.de/reverse-engineering-the-buderus-km217/ Die komplette Konfiguration für ESPhome werde ich bei Gelegenheit auch noch pushen. Wer mich bei der Software unterstützen will ist jederzeit willkommen. Das Repo findet sich hier: https://gitlab.com/the78mole/logamatic_2107_wifi_comm Viel Spaß :-) PS: Wer eine Platine will, bitte noch die postialische Adresse an mich schicken. Entweder per PM oder über Email (findet sich auch im Impressum meines Blogs).
:
Bearbeitet durch User
Hallo Zusammen! Vielen Dank an alle die hier mitgeholfen haben, die nötigen Protokollinformationen zu erarbeiten. Falls Interesse besteht, ich habe auf GitHub ein Projekt hochgeladen, welches wunderbar zusammen mit der Platine von Daniel funktioniert. Es liefert alle mir bisher bekannten Werte per MQTT und kann auch einige Werte per MQTT Befehle anpassen und steuern. Ihr findet es hier: https://github.com/dewenni/ESP_Buderus_KM271 Grüße Sven
Sven T. schrieb: > Ihr findet es hier: https://github.com/dewenni/ESP_Buderus_KM271 Hallo Sven, 1000x Danke an dich! Ich bin da schon länger dran und hatte bisher auch keine Hardware dazu. Bestellung ist schon raus - das iiiiiideale Weihnachtsprojekt 👍🤣👏 Schöne Grüße!
Hallo Jungs, ich habe nun fast keine Module mehr und sammele gerade Ideen, die ich noch mit umsetzen könnte... Aktuell auf der Liste: - OneWire Interface connector - Add-On Connectors (some I/Os, I2C, SPI) Wer noch gute Ideen hat, die mit den recht generischen beiden Sachen nicht abgedeckt sind, einfach hier rein :-) Grüße, Daniel
Daniel G. schrieb: > Hallo Jungs, > > ich habe nun fast keine Module mehr und sammele gerade Ideen, die ich > noch mit umsetzen könnte... Aktuell auf der Liste: > > - OneWire Interface connector > - Add-On Connectors (some I/Os, I2C, SPI) > > Wer noch gute Ideen hat, die mit den recht generischen beiden Sachen > nicht abgedeckt sind, einfach hier rein :-) > > Grüße, > Daniel Hallo Daniel, an dieser Stelle einfach mal danke dir für deine Arbeit und Mühen die du in dieses Projekt steckst 👍👌 (Hatte fast schon befürchtet, du hast keine Zeit mehr gefunden um an dem Projekt weiter zu machen) Gruß - Markus
Hi Markus, tatsächlich hatte ich kaum Zeit, deswegen habe ich ja bestückte Platinen bestellt. Dass ich dann so viele Bestellung in so kurzer Zeit wegarbeiten muss, im Gegenzug aber drei tolle Personen (Sven, Jens, Bascht) aus der Community mir dann die Arbeit in der Firmware abnehmen, damit hatte ich nicht gerechnet. Vermutlich werde ich noch vor Weihnachten noch ein paar neue Features in die Hardware einarbeiten und dann bestellen. Ich bin auch echt begeistert, was da für eine Resonanz auf das Projekt kam... Ich hatte Bestellungen aus Deutschland, USA, Lettland, Polen, Ungarn, Litauen, Belgien, Spanien und Estland. Völlig crazy :-P Grüße, Daniel
Das Projekt ist auch für mich hochgradig interessant. Vor einigen Monaten war ich schon darauf gestoßen, als ich die Logamatic wegen eines defekten Brennerrelais reparieren musste und (mal wieder...) Ausschau nach einer Kommunikationskarte hielt. Grundsätzlich würde ich aber lieber dem bewährten Motto "Wer Funk kennt, nimmt Kabel!" folgen, obwohl sich der relevante WLAN-AP direkt über dem Heizungskeller befindet. Daher hatte ich auch schon darüber nachgedacht, Deine Leiterplattenkontur zu "klauen" und als Grundlage für eine Ethernetversion zu verwenden. Ggf. wäre es durchaus interessant, den Ethernet-Teil mit IP101 an "Deinen" ESP32 dranzuknüppern, ähnlich wie hier: https://docs.espressif.com/projects/esp-idf/en/latest/esp32/hw-reference/esp32/get-started-ethernet-kit.html Offenbar scheint ja die Spannungsversorgung von Buderus nicht auf ein WLAN-Modul (oder auch Ethernet) ausgelegt zu sein, so ich erwäge, auch eine separate Stromversorgung vorzusehen oder zumindest eine höhere Spannung an anderer Stelle der Logamatic abzugreifen. Nachdem mir Altium ein Ultimatum bezüglich einer möglichen Wiederaufnahme/Verlängerung von Wartung und Software-Updates gestellt hat, ist für mich auch endgültig klar, auf KiCad umzustellen. Somit wäre das o.a. ohnehin schon für KiCad vorliegende Projekt auch ein schöner Testballon (neben anderen beruflichen und privaten Projekten).
:
Bearbeitet durch User
Hallo Daniel, ein sehr interessantes Projekt :-) Für mich wäre der OneWire Anschluss sehr interessant - dann würde ich mir meine aktuelle Platine für meinen Pufferspeicher + Temperaturen vor & nach der Systemtrennung mit 8 x DS18B20 sparen :-) - falls die Spannungsversorgung der Logamatic das mitmacht.. Viele Grüße
Hallo Jens, hallo Andreas, also mit dem WLAN des ESP32-WROOM-32D hab ich bisher nur gute Erfahrungen gemacht, was die Reichweite und Zuverlässigkeit angeht. Der Charme liegt ja gerade darin, dass ich keine Leitungen ziehen muss. Grundsätzlich könnte man aber auch einen ENC28J60 an die SPI-Schnittstelle andödeln. Für ESP32 gibt es da durchaus Quellcode. https://github.com/tobozo/ESP32-ENC28J60 Ethernet (über MII) direkt am WROOM verbrät halt unglaublich viele GPIOs. Bezüglich Spannungsversorgung hatten meines Wissens bisher nur zwei Bastler Probleme. Bei den anderen (mehr als 50 Personen) lief alles wie am Schnürchen. Und auch bei mir bisher keinerlei Probleme. Ich vermute fast, dass bei den beiden Problem-Steuerungen entweder irgendwas angeschlossen ist, das viel Saft braucht oder das Netzteil ein Montagsmodell ist. Natürlich könnte man auch einen DC/DC verbauen. Der würde die Sache sicher deutlich entspannen, verbraucht aber auch wieder Platz und kostet deutlich mehr als der kleine LDO. Und die paar zehn Milliwatt Verluste sind auch nicht der Rede wert. Die OneWire-Sensoren ziehen auch praktisch keinen Strom. Würden sie das tun, würden sie sich auch selbst zu stark aufheizen, um noch anständig zu messen. KiCad kann ich tatsächlich nur empfehlen. Habe damit nun schon etliche Projekte gemacht und wenn man sich an ein paar Regeln hält, dann ist es eines der besten PCB-Tools, die ich je verwendet habe. z.B. die Original-Bibliotheken per GIT holen und in Ruhe zu lassen, die eigenen Symbole und Packages dann in ein eigenes GIT zu stecken. Außerdem sollte man für die Pfade entsprechend Variablen definieren. Mal sehen, ob ich es noch vor Weihnachten schaffe oder dann "zwischen den Jahren" dazu komme. Grüße, Daniel
:
Bearbeitet durch User
Daniel G. schrieb: > Der > Charme liegt ja gerade darin, dass ich keine Leitungen ziehen muss. Der Charme von Ethernet liegt ja gerade darin, dass man bei einem Gerätetausch eines Switches nur die Patchkabel umstecken muss. Bei WLAN muss man wiederum alle Clients in den neuen Access Point einbuchen, was ja gerade bei Geräten ohne eigenes GUI o.ä. mit ziemlicher Bastelei verbunden sein kann. Und irgendwelche Smart-Home-Komponenten sind ja auch defür prädestiniert, bei solch einer Aktion vergessen zu werden.
Hi Andreas, wenn man das WLAN gleich konfiguriert sollte alles wie vorher laufen, selbst mit Consumer-Geräten. Wenn ich bei mir einen AP tausche oder einen neuen dazu hänge, wird der automatisch provisioniert und alle Clients können den wie gehabt nutzen. Wer Ethernet haben möchte, der kann meine "bare PCB-Variante" und einen Raspi oder irgend einen anderen Ethernet-UART-Konverter kaufen. Den wenigen noch verfügbaren Platz auf dem Board nutze ich lieber für andere Dinge als einen Ethernet-Anschluss (Stecker, Übertrager, Hühnerfutter), den gerade mal 1% der Interessenten nutzen will. Zumal der ESP ja gerade für WLAN (und vielleicht noch Bluetooth) prädestiniert ist. Grüße, Daniel
Daniel G. schrieb: > Den > wenigen noch verfügbaren Platz auf dem Board nutze ich lieber für andere > Dinge als einen Ethernet-Anschluss (Stecker, Übertrager, Hühnerfutter), > den gerade mal 1% der Interessenten nutzen will. Genau, das verlange ich ja auch gar nicht. Oben hatte ich ja geschrieben, dass ich vermutlich Deine Leiterplattenkontur usw. für meine eigene Variante verwenden werde. Sofern ein Interesse besteht, wäre ich dann durchaus auch bereit, das ganze wieder zuveröffentlichen, ggf. auch in einem gemeinsamen Git-Repository. > Zumal der ESP ja gerade > für WLAN (und vielleicht noch Bluetooth) prädestiniert ist. In der Tat wäre er - ohne "Projektaltlasten" nicht der Controller erster Wahl, wenn man WLAN gar nicht nutzen will.
Hi Andreas, gerne kannst Du das Design nutzen und Dein eigenes veröffentlichen. Ich verlinke natürlich auch gerne Dein Repo auf meinen Seiten (GitLab, GitHub, mein Blog,...) und würde mich auch freuen, wenn Du mich umgekehrt verlinkst. Grüße, Daniel
Hallo zusammen, meine Platine ist heute angekommen 👍👌😁 Ich gerade dabei, die Version von Sven auf das Modul zu laden. Das klappt soweit auch, allerdings bootet das Modul dann nicht mehr. Die LEDs leuchten auch nicht mehr. Im Serialmonitor seh ich nur, dass das Modul in einer Bootschleife hängt:
1 | Brownout detector was triggered |
2 | |
3 | ets Jun 8 2016 00:22:57 |
4 | |
5 | rst:0xc (SW_CPU_RESET),boot:0x17 (SPI_FAST_FLASH_BOOT) |
6 | configsip: 0, SPIWP:0xee |
7 | clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00 |
8 | mode:DIO, clock div:2 |
9 | load:0x3fff0030,len:1184 |
10 | load:0x40078000,len:13132 |
11 | load:0x40080400,len:3036 |
12 | entry 0x400805e4 |
13 | |
14 | Brownout detector was triggered |
15 | |
16 | ets Jun 8 2016 00:22:57 |
17 | |
18 | rst:0xc (SW_CPU_RESET),boot:0x17 (SPI_FAST_FLASH_BOOT) |
19 | configsip: 0, SPIWP:0xee |
20 | clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00 |
21 | mode:DIO, clock div:2 |
22 | load:0x3fff0030,len:1184 |
23 | load:0x40078000,len:13132 |
24 | load:0x40080400,len:3036 |
25 | entry 0x400805e4 |
Das wiederholt sich ständig. Jemand eine Idee, wo das Problem liegt? Gruß - Markus
Kommt der Brownout weil das Modul momentan nur an der seriellen Schnittstelle des Rechners hängt? Sprich: muss das Modul zur Inbetriebnahme im Sockel der Heizungssteuerung stecken?
Okay, in meiner Teststeuerung leuchten jetzt mal alle LEDs und kurz ist das Modul auch mit WLAN verbunden. Bricht aber nach einiger Zeit ab und connectet sich dann neu. Was mach ich noch falsch? Muss an den Jumperleisten noch was umgesteckt werden? Hab ich so gelassen, wie sie im Lieferzustand waren.
:
Bearbeitet durch User
Das könnte an einer nicht funktionierenden MQTT Verbindung liegen. Es ist im Code so implementiert, dass bei WiFi und MQTT 5 Verbindungsversuche mit jeweils 5s Abstand erfolgen. Nach 5 erfolglosen Versuchen sich mit dem WLAN oder MQTT Server zu verbinden, macht der ESP einen Restart. WiFi und MQTT müssen also funktionieren.
Und du brauchst den Jumper auf P4 damit die Logamatic die Platine erkennt. Der Jumper fehlte bei mir im "Auslieferungszustand" Die nötigen Jumper kannst du hier vergleichen: https://github.com/dewenni/ESP_Buderus_KM271/wiki/1.-Hardware-Setup
Sven T. schrieb: > Und du brauchst den Jumper auf P4 damit die Logamatic die Platine > erkennt. Der Jumper fehlte bei mir im "Auslieferungszustand" > > Die nötigen Jumper kannst du hier vergleichen: > https://github.com/dewenni/ESP_Buderus_KM271/wiki/1.-Hardware-Setup Vielen Dank für deine Tipps! Werde ich morgen gleich testen 👍👌
Hi Markus,
> Vielen Dank für deine Tipps! Werde ich morgen gleich testen 👍👌
Falls Du weiter Probleme mit Brown-Out hast, in seltenen Fällen (bisher
2 von 70) scheint die Buderus aus unerfindlichen Gründen eine schwache
Stromversorgung zu haben. Kann sein, dass da irgendwelche
Zusatzkomponenten drin sind, die mehr Strom ziehen. Bei mir funktioniert
das Modul nun seit Monaten in diversen Entwicklungsstufen einwandfrei.
Nur anfangs hatte ich noch Probleme, als auf der 3,3V-Schiene zu wenig C
(nur 100 nF) verbaut war. Auch die neueste Stufe mit den Level-Shiftern
auf der seriellen Schnittstelle zum Buderus, wie ich sie auch verkaufe,
läuft ohne einen einzigen Aussetzer.
Um dem Problem auf den Grund zu gehen, kannst Du einfach mal den
5V-Jumper raus nehmen und das Modul mit 3,3V über die
Programmierschnittstelle versorgen. Da eignet sich auch der
USB-seriell-TTL-Adapter gut, wenn dieser 3,3V zur Verfügung stellt
(Achtung: Keine 5V, die könnten den ESP beschädigen).
Wenn es dann funktioniert würde mich brennend interessieren, woran das
liegt :-)
Ursache gefunden! Ich habe meinen mqtt Server auf einem anderen Port laufen und in deinem Code war der Port 1883 fest vorgegeben. Ich habe die Credentials.h um die Angabe
1 | #define MQTT_PORT 1884
|
erweitert sowie die mqtt.cpp geändert
1 | mqtt_client.setServer(MQTT_SERVER, MQTT_PORT); |
Damit funktioniert der Aufbau der Verbindung auf Anhieb. Danke nochmal für deinen Hinweis 👍🙋♂️
prima, dann nehme ich das mal noch mit auf. Sowohl im Code als auch in der Beschreibung.
Daniel G. schrieb: > Hi Markus, > >> Vielen Dank für deine Tipps! Werde ich morgen gleich testen 👍👌 > > Falls Du weiter Probleme mit Brown-Out hast, in seltenen Fällen (bisher > 2 von 70) scheint die Buderus aus unerfindlichen Gründen eine schwache > Stromversorgung zu haben. Kann sein, dass da irgendwelche > Zusatzkomponenten drin sind, die mehr Strom ziehen. Bei mir funktioniert > das Modul nun seit Monaten in diversen Entwicklungsstufen einwandfrei. > Nur anfangs hatte ich noch Probleme, als auf der 3,3V-Schiene zu wenig C > (nur 100 nF) verbaut war. Auch die neueste Stufe mit den Level-Shiftern > auf der seriellen Schnittstelle zum Buderus, wie ich sie auch verkaufe, > läuft ohne einen einzigen Aussetzer. > > Um dem Problem auf den Grund zu gehen, kannst Du einfach mal den > 5V-Jumper raus nehmen und das Modul mit 3,3V über die > Programmierschnittstelle versorgen. Da eignet sich auch der > USB-seriell-TTL-Adapter gut, wenn dieser 3,3V zur Verfügung stellt > (Achtung: Keine 5V, die könnten den ESP beschädigen). > > Wenn es dann funktioniert würde mich brennend interessieren, woran das > liegt :-) Hi Daniel, ich habe den Jumper gezogen, hat aber keinen Unterschied gemacht! In der seriellen Konsole kamen trotzdem die Brownout Meldungen. Steckt das Modul aber in der Steuerung, läuft das ganze ohne Aussetzer! Die nächsten Tage werden dann zeigen, wie stabil es läuft. Sehe aber auch keine Einschränkungen hinsichtlich der Stabilität. Gruß
Hi Markus, > ich habe den Jumper gezogen, hat aber keinen Unterschied gemacht! In der > seriellen Konsole kamen trotzdem die Brownout Meldungen. Steckt das > Modul aber in der Steuerung, läuft das ganze ohne Aussetzer! > Die nächsten Tage werden dann zeigen, wie stabil es läuft. Sehe aber > auch keine Einschränkungen hinsichtlich der Stabilität. Achso, der Programmieradapter liefert nicht genug Saft... Na dann bringt Jumper-Ziehen natürlich wenig. Der trennt den LDO ja nur auf der 5V-Seite ab. Die Ausgangsseite ist immer verbunden, sollte aber nicht viel ausmachen, wenn man "von hinten" versorgt. Wenn Du die Situation öfter hast, dass Du außerhalb der Buderus was testen willst, dann solltest Du evtl. über den Debug-Header die 5V z.B. von USB versorgen. Grüße, Daniel
Daniel G. schrieb: > Wenn Du die Situation öfter hast, dass Du außerhalb der Buderus was > testen willst, dann solltest Du evtl. über den Debug-Header die 5V z.B. > von USB versorgen. > > Grüße, > Daniel Ich hab auch noch andere Adapter, mit verschiedener Bauart. Ich teste einfach mal mit einem anderen. Aber das ist für mich auch nicht wirklich entscheidend, die Programmierung läuft sauber und in der Steuerung funktioniert dann auch alles 👍 Was mir gestern auf die Schnelle aufgefallen ist: die ganzen Stati der Werte beziehen sich immer nur auf den Heizkreis 1. Bei mir an der Teststeuerung als auch an der "richtigen" Steuerung ist Heizkreis 2 aktiv. Warum weiß ich ehrlich gesagt nicht. Kann ich dann damit überhaupt meine Steuerung ansprechen sprich auch den Heizkreis 2 abfragen und steuern? Gruß - Markus
Ich habe jetzt die Doku zu meiner HS 2105M gewälzt und rausgefunden, warum da HK2 aktiviert ist. Weil nur am HK2 der Mischerbetrieb möglich ist. Auf meiner Teststeuerung habe ich nun HK1 aktiviert und kann auch per Befehl die Einstellungen steuern, funktioniert perfekt. Aber eben nur für den HK1. Hab ich mit der Lösung eine Chance die Daten von HK2 irgendwie abzugreifen? Anscheinend müsste hier die Protokollauswertung erweitert werden oder?
:
Bearbeitet durch User
Sven: funktioniert bei dir das Uhrzeit stellen? Macht bei mir gar nix wenn ich den Befehl per mqtt absetze.
Das Uhrzeit Stellen hat an meiner Logamatic 2107 funktioniert. Es wird dann die Uhrzeit gesetzt, die per NTP Server ermittelt wurde. Die Uhrzeit die im ESP aktuell verwendet wird, siehst du auch in der WiFi Struktur die per MQTT gesendet wird. Möglicherweise hat die HS 2105M aber auch andere Adressen dafür. Das kann ich nicht sagen. Bezüglich HK1 und HK2: Ich habe mich bei der Software auf HK1 konzentriert, weil ich nur den HK1 habe und mich die Werte von dem nicht vorhandenen HK2 nicht interessiert haben. Natürlich könnte man den HK2 auch noch mit dazu nehmen und es ggf. konfigurierbar machen. Dokumentiert ist der HK2 hier auch: https://github.com/mhop/fhem-mirror/blob/master/fhem/FHEM/00_KM271.pm Der Aufwand dürfte sich in Grenzen halten. Ich kann dir aber nicht versprechen das ich das kurzfristig schaffe. Muss mal schauen. Vielleicht am kommenden Wochenende. Grüße Sven
Sven T. schrieb: > Das Uhrzeit Stellen hat an meiner Logamatic 2107 funktioniert. > Es wird dann die Uhrzeit gesetzt, die per NTP Server ermittelt wurde. Ich würde das ganze sogar fast umkehren und die Logamatic als Zeitserver verwenden. Ich fragte mich übrigens jahrelang, warum das Datum und die Uhrzeit immer korrekt waren. Erst bei der diesjährigen Renovierung unseres Wohnzimmers öffnete ich die Fernbedienung und entdeckte darin den DCF-77-Empfänger. Hat eigentlich jede 2107-basierte Heizungsanlage einen DCF-77-Empfänger?
Hallo Andreas,
> Hat eigentlich jede 2107-basierte Heizungsanlage einen DCF-77-Empfänger?
Also meine sicherlich nicht :-P
Es gäbe aber auch noch eine andere Variante, wie man eine sehr genaue
Zeitbasis haben kann: Die 50 Hz Netzfrequenz. Früher wurde die mal genau
nach Atomuhr ausgeregelt. Heute ist das aber meines Wissens nicht mehr
so scharf, aber vermutlich noch immer besser als jeder billige
Uhrenquartz.
Übrigens, in "meiner" ESPhome-Variante ist auch HK2 bereits zum größten
Teil integriert, allerdings sind wir in anderen Bereichen noch nicht so
weit wie Sven.
Grüße,
Daniel
Sven T. schrieb: > Natürlich könnte man den HK2 auch noch mit dazu nehmen und es ggf. > konfigurierbar machen. > Dokumentiert ist der HK2 hier auch: > https://github.com/mhop/fhem-mirror/blob/master/fhem/FHEM/00_KM271.pm Danke für den Link! Ich schau da mal selber und versuche, die Werte selber einzubauen. Denke dass ich da viel spicken kann. Muss ja nicht immer nur einer die ganze Arbeit machen 🤣😉 Das mit der Uhrzeit ist auch ned so tragisch, nützlich wäre es halt. Aber erstmal ist der HK2 für mich wichtiger, sonst bringt mir das ganze Projekt nicht viel. Grüße - Markus
Daniel G. schrieb: > Es gäbe aber auch noch eine andere Variante, wie man eine sehr genaue > Zeitbasis haben kann: Die 50 Hz Netzfrequenz. Es wäre mir neu, dass auch die Uhrzeit über die Netzfrequenz übertragen wird. Das ganze taugt eben nur als Frequenznormal und nicht als Zeitnormal. > Früher wurde die mal genau nach Atomuhr ausgeregelt. Offenbar verwechselst Du die Netzfrequenz mit der Zeilenfrequenz der analogen öffentlich-rechtlichen Fernsehsender. Bezüglich der Netzfrequenz werden jedoch nach wie vor die Einzelschwingungen aufsummiert und nach Möglichkeit im Laufe einiger Monate so weit ausgeglichen, dass sich der Fehler netzfrequenzsynchronisierter Uhren nicht immer weiter kumuliert, sondern auf insgesamt nur einigen Minuten begrenzt bleibt. > Heute ist das aber meines Wissens nicht mehr > so scharf, aber vermutlich noch immer besser als jeder billige > Uhrenquartz. Genau das trifft auf die Zeilenfrequenz zu. Wie die Synchronisation aller Fernsehsender, die bei DVB-x zu einem Bouquet gebündelt werden, ist mir aber nicht bekannt. Früher(tm) lief ja die gesamte Produktionskette streng synchron, d.h. vom primären Frequenz- und Timinggenerator bis hin zu den Studiokameras. Dadurch konnte man dann auch mit sehr wenig Aufwand zwischen verschiedenen Kameras auch weich überblenden. Irgendwann gab es dann sog. digitale Time Base Correctors, d.h. Bildspeicher, mit denen sich Phasen- und Frequenzunterschiede asynchroner Videoquellen wieder ausbügeln ließen.
Lieber Daniel, Deine Platine habe ich diese Woche erhalten, super! Am Wochenende kommt mit der Installation der Moment der Wahrheit... Verflixt, ich meine entweder hier, auf github oder tindie gelesen zu haben, dass die Platine 1mm zu breit für den Slot ist. Ich find´s nicht mehr. Wenn ja, trifft das auch für die bestückte Platine zu? Muss ich feilen? Achim
Achim W. schrieb: > Lieber Daniel, > Deine Platine habe ich diese Woche erhalten, super! Am Wochenende kommt > mit der Installation der Moment der Wahrheit... > > Verflixt, ich meine entweder hier, auf github oder tindie gelesen zu > haben, dass die Platine 1mm zu breit für den Slot ist. Ich find´s nicht > mehr. > > Wenn ja, trifft das auch für die bestückte Platine zu? Muss ich feilen? > > Achim Hi Achim, ich glaub das war mal in einer der ersten Versionen der Platine. Habe meine vor ein paar Tagen bekommen, die passte ohne Anpassung in den Slot! Gruß
So, ich habe den Heizkreis 2 jetzt in meinem Code ergänzt. Sowohl bei den Config Werten als auch bei den Status Werten und den Befehlen. https://github.com/dewenni/ESP_Buderus_KM271 Markus: es wäre gut wenn du das mal testen könntest und mir Rückmeldung geben würdest ob es funktioniert.
Hallo Achim, > Verflixt, ich meine entweder hier, auf github oder tindie gelesen zu > haben, dass die Platine 1mm zu breit für den Slot ist. Ich find´s nicht > mehr. > > Wenn ja, trifft das auch für die bestückte Platine zu? Muss ich feilen? Das ist Vergangenheit (Version 0.0.1). Die 0.0.5 sollte perfekt passen. Zumindest hat sie das bei mir und gehört habe ich auch nichts mehr :-) Grüße, Daniel
Sven T. schrieb: > So, ich habe den Heizkreis 2 jetzt in meinem Code ergänzt. > Sowohl bei den Config Werten als auch bei den Status Werten und den > Befehlen. > > https://github.com/dewenni/ESP_Buderus_KM271 > > Markus: es wäre gut wenn du das mal testen könntest und mir Rückmeldung > geben würdest ob es funktioniert. Hallo Sven, vielen Dank für deine Arbeit 👌 Ich war auch schon fast fertig bzw. war grad beim testen. Ich habe mir deine neue Version gezogen und getestet. Funktioniert soweit ich es getestet habe alles wie gewünscht! Lediglich Uhrzeit stellen mag er immer noch nicht?!? Was mir dabei auffällt, da kommt auch keine Bestätigungsnachricht zurück. Wenn ich z.B. die Betriebsart ändere, dann kommt eine received Bestätigung zurück. Bei der Uhrzeit aber nicht. Oder ist das doch eine Registersache? Gruß - Markus
Okay - ich hab den Fehler gefunden wegen der Uhrzeit! 😂🤣 Ein Blick in die mqtt.cpp hat mir verraten, dass das Topic so aussehen muss: /esp_heizung/cmd/setdatetime Bei dir im Github stehts anders: esp_heizung/setvalue/setdatetime Kannst du ja mal bei Gelegenheit ändern. Andererseits schadet es nicht, dann geht man auch mal selber auf die Suche und ruht sich nicht auf der Arbeit anderer aus. 😁😉 Nochmals vielen Dank an dich für deine viele Arbeit! Gruß - Markus
perfekt, genau das habe ich auch gerade festgestellt. Dann ändere ich das im Code am besten auch mal auf "setvalue". Am besten schicke ich auch in der Antwort dann Uhrzeit und Datum mit zurück: message: datetime set to: 17.12.2022 - 16:07:35
Sven T. schrieb: > perfekt, genau das habe ich auch gerade festgestellt. > > Dann ändere ich das im Code am besten auch mal auf "setvalue". > > Am besten schicke ich auch in der Antwort dann Uhrzeit und Datum mit > zurück: > > message: datetime set to: 17.12.2022 - 16:07:35 Supi! Habe das Modul gerade in meine produktive Steuerung eingebaut. Funktioniert super und die gelieferten Werte passen auch alle. Jetzt muss ich das alles noch in mein NodeRed reinbasteln und die Märsche in den Keller runter sind Vergangenheit! 👌 Geniales Projekt - sowohl Hardware als auch Software.
so, ist geändert auf "/setvalue/setdatetime" und als Antwort kommt: "message: date and time set to: 17.12.2022 - 16:22:28 - DST:0" DST zeigt an ob das Sommerzeit Flag in der Logamatic gesetzt wurde Falls sonst noch was auffällt oder Wünsche bestehen, bitte melden. Entweder hier oder als "Issue" im GitHub.
Sven T. schrieb: > Falls sonst noch was auffällt oder Wünsche bestehen, bitte melden. > Entweder hier oder als "Issue" im GitHub. Ja mir ist jetzt tatsächlich noch was aufgefallen! In der km271.cpp hast du in den Abschnitten für den Hk2 die mqtt Topics von HK1 kopiert und dann den Text nicht geändert. So werden jetzt auch bei HK2 alle Statusmeldungen als HK1 ausgeliefert.
Daniel G. schrieb: [...] >> Wenn ja, trifft das auch für die bestückte Platine zu? Muss ich feilen? > > Das ist Vergangenheit (Version 0.0.1). Die 0.0.5 sollte perfekt passen. Hallo Daniel, hallo Leute, die Platine passt, super! Nach Einbinden ins Haus-WLAN und ESPHome/Homeassistant kamen auch plausible Werte, aber nur kurzzeitig. Nach kurzer Zeit keine Werte mehr. Ich habe noch versucht die YAML anzupassen (im Abschnitt ESPHome oder Configuration.yaml?). Jedenfalls war dann ein Ausrufezeichen beim km271-for-friends. Dann noch das Modul dort "gelöscht" und jetzt komme ich an nichts mehr ran. Auch nicht über den FallbackHotspot. Bislang habe ich nur mit ESP32DevKits gearbeitet und musste vorhin erstmal einen Programmer ordern. Dann gibts eine neue Firmware drauf für einen definierten Zustand --> damit alles auf Anfang. Schönen 4. Advent Achim
Angehängte Dateien:
Kleine Ergänzung, bisserl OT: Ich habe mit einem ESP32 Devkit, einem Ultraschall-Entfernungssensor und einem selbstgedruckten Gehäuse ein Projekt für einen Ölstandssensor im ESPHome/Homeassistant nachgebaut. Läuft seit 10 Monaten einwandfrei in einem Schütz-Öltank. Link zum Projekt und herzlichen Dank an den Projektersteller: https://forum.iobroker.net/topic/30434/%C3%B6lstandsmesser-selfmade Achim
Angehängte Dateien:
-
Abgastemperatur.png
39 KB
Achim W. schrieb: [...]> > Dann gibts eine neue Firmware drauf für einen definierten Zustand --> > damit alles auf Anfang. Kleiner Erfahrungsbericht, eher ESPHome/HomeAssistant bezogen: 1. möglicherweise war das km271-for-friends-Modul von Daniel von mir nicht sauber im Steckplatz eingerastet, wäre ein Grund für die ausbleibenden Werte (hat aber grün geblinkt); 2. neu Flashen ging nur mit ESPTool.exe (Windows 11, HomeAssistant ohne SSL, bin-File aus den Repos); 3. das ESPHome-Addon in HA hat dann fortwährend Devices als "adoptable" gezeigt, ohne dass das funktioniert hätte. Händisches Einbindungen des neu geflashten und ins WLAN eingebundenen km271-for-friends führte zu einem Gerät ohne Entities. Mein ESP32-Ölstandsmesser (siehe Post drüber) funktionierte nach stundenlangem rumtüfteln auch nicht mehr; 4. testweise eine Homeassistant in einem Dockercontainer gestaret. Zwar keine Addons, aber sofortige Einbindung des ESP32-Ölstandsmessers UND des km271-for-friends und Anzeige der Werte im Dashboard. Kleines Problem: die Abgastemperatur ist nicht plausibel und steht ohne Brennertätigkeit bei 255°C, bei Brennertätigkeit sind niedrige einstellige °C Temperaturen. So als wäre der Wert umgekehrt. Habt ihr das auch? Das Bild in der Anlage zeigt die UNterschiede. Bei den niedrigen Temperaturen war der Brenner in Betrieb, bei 255 °C nicht. ToDo: --> ursprüngliche Homeassistant-Installation auf einem Raspi muss wohl neu aufgesetzt werden, denn leider fehlen im HA-Container die Add-On-Möglichkeiten für DeConz - für mich essentiell. --> heute nicht mehr Achim
@Sven T.: Hi Sven, nachdem ich mit Verzückung deine Aktualisierungen heute gesehen habe, wollte ich diese gleich nutzen. Nachdem Upload der Version kam aber schnell die Ernüchterung! Nachdem ich gesehen habe, dass sowohl die WLAN-Verbindung als auch die mqtt-Verbindung ständig abbrechen, vermute ich dass der ESP mit der Version ständig einen Reboot macht. In der kurzen Zeit mit WLAN Verbindung kamen nur die wifi und die info Message rein, sonst nichts. Das aktivierte debug spuckte folgendes aus:
1 | 03_00_01_09_44_55_82_ba |
Ich hab jetzt wieder die v1.0.0 drauf, mit der läuft alles stabil. Keine Aussetzer bei WLAN als auch am mqqt-Broker. Bei dir läuft das stabil nehme ich mal an oder? Hat sonst jemand die aktuelle Version getestet? Gruß - Markus
Hallo Markus, evtl. wäre es geschickter, Probleme als Issue auf GitHub zu posten... Dieser Thread ist ohnehin schon viel, viel zu lang ;-) Grüße, Daniel
Hallo Markus, danke für das Feedback, auch wenn es nicht erfreulich ist. Ja bei mir läuft die neuste Version natürlich. Der Hinweis mit der der letzten empfangenen Debug Message hilft mir auch schon mal weiter. Die 03 00 ist der erste von den 4 Fehlereinträgen aus der Logamatic die ich zuletzt noch ergänzt habe.
1 | 03 00 ... |
2 | 03 07 ... |
3 | 03 0e ... |
4 | 03 15 ... |
Ich habe das anhand dem FHEM Code umgesetzt. Ein von mir provozierter Fehler liefert dann z.B. folgende Nachricht:
1 | 03_00_31_13_2a_00_13_2a_04_00_00 |
1 | 03_00 = erster Eintrag |
2 | 31 = "Kesselvorlauffuehler defekt" |
3 | 13 = 19 Uhr |
4 | 2a = 42min |
5 | 00 = Tage (muss später addiert werden) |
6 | 13 = 19 Uhr |
7 | 2a = 42min |
8 | 04 = 4 Tage |
Ergebnis: Kesselvorlauffuehler defekt (>> 19:42 -4 Tage | << 19:42 -4 Tage) Wenn ich mir aber deine Nachricht anschaue, dann passt das nicht:
1 | 03_00_01_09_44_55_82_ba |
Das geht schon bei der Fehlerummer "01" los. Die ist gar nicht definiert.
1 | 0 => "Kein Fehler", |
2 | 2 => "Aussenfuehler defekt", |
3 | 3 => "HK1-Vorlauffuehler defekt", |
4 | 4 => "HK2-Vorlauffuehler defekt", |
5 | .... |
Könnte also sein das die HS 2105M hier etwas anders funktioniert bzw. andere Werte liefert. Wäre schön wenn du nochmal was testen könntest. Nimm nochmal den letzten Stand und kommentiere die Stellen mit den 4 Fehlermeldungen aus. In der km271.cpp vor der ersten case mit 0x0300 bis nach der case 0x0315
1 | /* |
2 | case 0x0300: // 0x0300 : Error Buffer 1 |
3 | ... |
4 | case 0x0307: // 0x0307 : Error Buffer 2 |
5 | ... |
6 | case 0x030e: // 0x030e : Error Buffer 3 |
7 | ... |
8 | case 0x0315: // 0x0315 : Error Buffer 4 |
9 | |
10 | */ |
Lade aber bitte nochmal den aktuellsten Commit runter den ich gerade eben hochgeladen habe. Dort habe ich die Anzahl der Elemente in der Debug Nachricht wieder erhöht. Versionsnummer ist die v1.3.2 Schick mir dann bitte mal den Inhalt aller 4 Fehlermessages:
1 | 03 00 ... |
2 | 03 07 ... |
3 | 03 0e ... |
4 | 03 15 ... |
Dann schauen wir mal weiter. Einerseits sollte egal welcher Inhalt nicht zu einem Absturz führen. Da muss ich meinen Code dann nochmal prüfen. Andererseits hätte ich gedacht das die Nachrichten auch bei der HS 2105M so aufgebaut sind wie bei einer R2107. Aber schauen wir dann mal. Grüße Sven
Hallo zusammen, wir (jensg, qschneider, the78mole) haben im Rahmen meines KM271-WiFi-Projektes mal die Parameter der Logamatic M2107 zusammengetragen und in ein Spreadsheet gepresst: https://docs.google.com/spreadsheets/d/1W-oVek6CUZ5GJo_8_TkeF2YykQjmGvg-QrWh0w_4kFQ/edit?usp=sharing Evtl. hilft das dem Ein- oder Anderen für seine Implementierung z.B. in FHEM oder Arduino/MQTT. Es ist zwar noch nicht 100%-ig komplett und sicher ist noch der ein oder andere fehler versteckt, aber daran lässt sich ja arbeiten :-) Grüße, Daniel (the78mole)
Angehängte Dateien:
Hallo, ich habe ein originales M404 KM2.0 Kommunikations-Modul für die Buderus Ecomatic 4000. Mit diesem Modul möchte ich gerne meine Heizung in Home Assistant einbinden. @Daniel Glaser (mailto:me@the78mole.de) Falls Du Interesse hast ein "Buderus Ecomatic 4000 Smart Home WiFi Modul" zu entwickeln, dann kann ich gerne detaillierte Fotos vom M404 Modul bereitstellen. Gruß Gernot
Angehängte Dateien:
-
s-l1600.jpg
390 KB
Gernot schrieb: > Hallo, > ich kann gerne detaillierte Fotos vom M404 Modul bereitstellen. Das ist ein Foto vom gesamten Modul. Es wird immer nur in einen Platinen-Stecker auf der Ecomatic 4000 (HS4201) Haupt-Platine eingesteckt. Gernot
Hallo Gernot, wozu soll denn die M404 überhaupt gut sein? Ist das einfach ein Kommunikationsmodul wie die Original-KM271 für eine andere Buderus-Steuerung? EDIT: Found your comment on my blog :-) Sorry to say, but since I don't have your logamatic unit, it is almost impossible to do all the engineering for another control unit. I think, the easiest way is to: - attach a USB-RS485-cable to the comm-module to see if the Logamatic is talking a similar protocol than my one If this is successful, attach an ESP32 with a RS485-Converter to the header of your communication module. And if this also succeeds, I could give it a try to reverse engineer the remaining parts and build a PCB for the HS4201. Cheers, Daniel (the78mole)
:
Bearbeitet durch User
Hallo Daniel, ja, das KM404 ist für die Ecomatic 4000 das Kommunikationsmodul. So wie das KM271 für die Logamatic 2107. Die Buderus Ecomatic 4000 (meine Heizung ist Baujahr 1996) ist sozusagen die Vorgänger-Generation. Das Kommunikationsmodul "M404 / KM2.0" ist nur sehr selten verkauft worden. EDIT: Yes, i will try to connect the M404 module via RS232 or RS485 and check the communication protocol. I will keep you updated... Fingers crossed :) Grüße, Gernot
:
Bearbeitet durch User
Hi Gernot, oh yes, I'm so, so, so looking forward to the results... If your control unit speaks the same "ugly language" like mine, then the chances are good, that we can attach many more Buderus control units and maybe even the newer ones. Regards, Daniel
Angehängte Dateien:
-
M404_Front_Devices.JPG
230 KB
Heute ist das KM2.0 M404 Kommunikationsmodul eingetroffen. Als erstes habe ich die Kontakte des Platinen-Stecker ausgemessen und die Signale anhand der IC-Datenblätter ermittelt. Bisherige Erkenntnisse siehe Foto. Gernot
Heute ist das KM2.0 M404 Kommunikationsmodul über RS232 (mit 2400 Baud) an eine ESP8266 angeschlossen und über den UART die Kommunikation im Debugger-Log angeschaut. Es wird von der Steuerung regelmäßig "\x02" ausgegeben. Wenn darauf "\x10" gesendet wird antwortet die Steuerung mit "\b\x03\x85\x10\x03\x9D" oder "\x11\x05:\x10\x03=" oder "a\x16\xFE\x10\x03\x9A" oder "B\x0F!\x10\x03" Kann jemand erkennen, ob die Kommunikation die selbe ist wie beim KM271 Modul. Gruß Gernot
Hallo Gernot, das sieht ganz stark nach dem 3964R-Protokoll aus, das auch die KM271 verwendet. Allerdings wird es sicher einige kleine Unterschiede in den Parametern geben. Aber das ist dann auch schon fast trivial und hauptsächlich Fleißarbeit: An der Steuerung umstellen und beobachten, was über die Schnittstelle kommt... Ich denke, die schnellste Vorgehensweise wäre, unsere KM271-Komponente für ESPhome zu nehmen und erst mal alles aus der YAML rauszuwerfen und dann ins Log zu schauen. Ich vermute aber, der ESP8266 ist schnell an seinen Grenzen, aber für erste Versuche könnte es reichen. Grüße, Daniel
Hallo Daniel, danke für die rasche Rückmeldung. Das hört sich gut an :) Für die weiteren Versuche habe ich mir schon einen ESP32 D1 Mini bestellt. So wie du angeraten hast, hatte ich eh vor mit eurer KM271-Komponente weiterzumachen. Die externe Beschaltung des ESP32 wird mit dem nötigsten ausgeführt - nach Vorlage der KM271-WiFi Karte. Gruß Gernot
Hallo Gernot, genau. Und im YAML einfach erst mal nur die Sections angeben, ohne Verweis auf die Datenpunkte. Leider gibt es einen fehler, wenn man die Sections (button, number,...) weg lässt (zumindest war das noch vor ein paar Tagen so).
1 | esphome: |
2 | name: buderus-km217 |
3 | platform: ESP32 |
4 | board: esp32dev |
5 | |
6 | # Enable logging |
7 | logger: |
8 | |
9 | # Enable Home Assistant API |
10 | api: |
11 | |
12 | ota: |
13 | password: "<blahblah>" |
14 | |
15 | wifi: |
16 | ssid: !secret wifi_ssid |
17 | password: !secret wifi_pass |
18 | |
19 | uart: |
20 | id: uart_bus |
21 | tx_pin: GPIO2 |
22 | rx_pin: GPIO4 |
23 | baud_rate: 2400 |
24 | |
25 | external_components: |
26 | - source: github://the78mole/esphome_components@main |
27 | components: [ km271_wifi ] |
28 | |
29 | km271_wifi: |
30 | - id: budoil |
31 | uart_id: uart_bus |
32 | |
33 | text_sensor: |
34 | - platform: km271_wifi |
35 | firmware_version: |
36 | name: "Firmwareversion Steuerung" |
37 | |
38 | button: |
39 | number: |
40 | select: |
41 | binary_sensor: |
42 | sensor: |
43 | switch: |
Und dann anfangen, die einfachen Datenpunkte einzubauen... Grüße, Daniel
Angehängte Dateien:
-
HA_ECOM-4K_000.png
220 KB
Hallo Daniel, inzwischen habe ich die Kommunikation über die RS232-Schnittstelle zum Laufen gebracht und die gesendeten Daten mit protokolliert. Aus der Analyse der Daten konnte ich ein paar erste Codes von Temperatur-Messwerten herausbekommen. Das ist echt eine Fleißarbeit... Gruß Gernot
Hi Gernot, die ganzen Parameter und möglichen Settings kannst Du Dir ganz einfach aus dem Code des KM271-Moduls rausziehen. Wir werden das demnächst auch noch etwas ausführlicher dokumentieren... Grüße, Daniel
Angehängte Dateien:
-
HA_ECOM-4K_004.png
40 KB
Hallo, inzwischen habe ich ein paar weitere Codes für Ist- und Soll-Temperaturen, sowie die Bedeutung ein paar Bits aus einem regelmäßig gesendeten Staus-Codes aus dem Datenprotokoll der HS4201 Steuerung entschlüsseln können und diese in Home-AssistAnt eingebunden. Die Codes der Ecomatic 4000 HS4201 Steuerung sind leider komplett anders und weniger Strukturiert als die Codes der Logamatic Steuerung. Gruß Gernot
Hallo Jungs, mir ist noch nicht ganz klar, was die Schnittstelle an Funktionen bietet. Mein Use Case wäre, die Heizkurve bequem auf der Couch mit dem Notebook auf dem Schoss einzustellen. Laut Bedienungsanleitung geht das ja nur mit der Kugelschreibermethode am Gerät. Gruß Matthias
Hallo Matthias, Du kannst über die Raumsolltemperatur (Parallelverschiebung) und die Auslegungstemperatur (Steigung) die Heizkurve bequem über das SmartHome verstellen, zumindest für alle Firware-Varianten, die ich kenne, die auf meinem Modul laufen. Leider bin ich aktuell leer-geräubert und werde frühestens im September wieder eine Charge der KM-271-ESP32-Module bestellen. (Verfügbar dann etwa einen Monat später). Unbestückte Platinen hätte ich noch ein paar wenige in der Schublade. Grüße, Daniel
:
Bearbeitet durch User
Hallo Daniel, unbestückte Platine würde reichen. Hast Du einen Link auf Dein Projekt zwecks Aufbau und Inbetriebnahme? Gibts eine "API"-Beschreibung zu den verfügbaren Funktionen? Gruß Matthias
Hallo Matthias, muss mich kurz fassen, Urlaub ist stressig 🤣... Hier solltest Du alles finden: https://the78mole.de/projects/km271-wifi-howto/, auch die Links zu GitLab und GitHub. Grüße, Daniel
Angehängte Dateien:
-
fehler_buderus.png
510 KB
Hallo zusammen, ich muss mal kurz diesen Thread kapern 😉 Ich hab auch Daniels Platine in der aktuellen 0.0.6 Variante im Betrieb. Hatte vorher eine andere Revision in Verwendung. Irgendwann kam mal durch Update bzw. Tausch der Platinen eine Fehlermeldung auf der Buderus Steuerung (sieh Bild). Und die bring ich nicht mehr weg, hab folgendes versucht: - Stromversorgung des Moduls über die USB Buchse -> Fehler immer noch da - Module ausgebaut, Steuerung in Betrieb genommen -> Fehler immer noch da - aktuelle 3.2.4 von Sven's Software installiert (per USB bzw. seriell) -> Fehler immer noch da Ansonsten funktioniert übrigens alles, sowohl mit der Heizung als auch mit dem Module. Es werden alle Parameter wie gewünscht per mqtt übertragen und die Steuerung via Webinterface funktioniert auch. Etwas Suche im Web brachte den Hinweis, dass man wohl auf Ebene 2 der Steuerung Module ein- bzw. ausprogrammieren kann. Kennt sich wer damit aus wie das geht? Im "normalen" Setup Modus find ich jedenfalls nix dazu. Grüße
:
Bearbeitet durch User
Hallo Markus, der Fehler deutet auf ein defektes oder fehlendes FM242 hin. https://www.manualslib.de/manual/15526/Buderus-Logamatic-2107.html?page=63 Hat deine Steuerung ein "2-Stufen Brenner Modul" FM242 ? Falls nur ein "1-Stufen Brenner Modul" FM241 eingebaut ist, dann solltest Du versuchen die Einstellungen entsprechend zu ändern. Siehe Service-Anleitung: https://www.manualslib.de/manual/15526/Buderus-Logamatic-2107.html?page=1 Gruß Gernot
Gernot A. schrieb: > Hallo Markus, > der Fehler deutet auf ein defektes oder fehlendes FM242 hin. > https://www.manualslib.de/manual/15526/Buderus-Logamatic-2107.html?page=63 > > Hat deine Steuerung ein "2-Stufen Brenner Modul" FM242 ? > Falls nur ein "1-Stufen Brenner Modul" FM241 eingebaut ist, dann > solltest Du versuchen die Einstellungen entsprechend zu ändern. > > Siehe Service-Anleitung: > https://www.manualslib.de/manual/15526/Buderus-Logamatic-2107.html?page=1 > > Gruß > Gernot Hi Gernot, danke für den Hinweis, ich hab das mal auf 1-stufig umgestellt und nun ist die Anzeige bzw. der Fehler weg. Ich weiß allerdings nicht wirklich, welches Modul da verbaut ist. Weißt du, wo ich das sehe? Ist das in der Steuerung oder am Brenner zu sehen? Gruß - Markus
Angehängte Dateien:
-
Logamatic_2107_FM241.jpg
410 KB -
FM241_000.png
360 KB -
FM242_000.png
230 KB
Hallo Markus, da musst du in die Logamatic 2107 reinschauen. Das FM241 ist das Mischer-Modul für den Heizkreis 2 (siehe Bild). Das FM242 wäre zur Ansteuerung eines 2-stufigen oder modulierenden Brenners nötig... Gruß Gernot
Gernot A. schrieb: > Hallo Markus, > da musst du in die Logamatic 2107 reinschauen. > Das FM241 ist das Mischer-Modul für den Heizkreis 2 (siehe Bild). > Das FM242 wäre zur Ansteuerung eines 2-stufigen oder modulierenden > Brenners nötig... > Gruß > Gernot Nochmals danke 👍 Diese Modul ist bei mir nicht verbaut, von daher passt jetzt alles wie es eingestellt ist. Gruß - Markus
Thread beobachten
Seitenaufteilung abschalten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.