Buderus Logamatic 2107 Revision 3 2019

[lips1]

Hallo,
ich hatte das Thema vor ein paar Jahren schon mal auf meiner Wunschliste.
Hatte mir dazu eine eigene Platiene gemacht, mit der ich das RS232 Signal abgreife und wahlweise per FTDI in USB wandle bzw. mit einem X-Port per Ethernet übertragen konnte.
Bin dann leider am Protokoll gescheitert. Um so mehr freut es mich, das es jetzt wohl möglich ist.

Aktuell greife ich mir alles direkt in der Steuerung ab und habe externe Sensoren zum messen der Temperaturen.
Was ich aktuell nicht kann und was mir fehlt, ist die direkte Beeinflussung aus der CCU heraus.

Bevor ich mich wieder intensiv mit dem Thema beschäftige, hätte ich zwei Fragen, ob das ganze für mich Sinn macht.
- Können aus der CCU heraus werte geändert werden? Also zb. die Vorlauftemperatur?
- Ich nutze als CCU einen Raspi mit Yahm. Auf der Rs232 steckt das Funmodul. Kann ich das auch mit dem FTDI und USB machen.

Danke.

Lips

[Black]

hi,

das protokoll ist ein lupenreines 3964r Protokoll, dass ein BCC mitsendet und wo die logamatic als lowPriotity läuft.

zusätzlich zu der Kommunikation sowohl zur ccu als auch zu iobroker hab ich da noch einen kleinen primi Webserver drauf programmiert,

folgende Istwerte liefert mir das Gateway aus der Logamatic:

Istwerte

und die folgenden Werte lassen sich sowohl von der CCU, als auch von IOBroker als auch über den Webserver per Get Ausfruf verändern:

Wenn dein USB RS232 Stick von dem Rasbian erkannt und auch unterstützt wird tuts die Kommunikation dadrüber auch,
du musst nur die Schnittstelle von ttyAMA0 (die GPIO RS232) nach ttyUSB0 umbenennen.

greetz und viel Erfolg,

Black

[oetzi]

Servus Black!
Meiner Logamatic2107 habe ein KM271 verpasst und mit RS232 des Raspi verbunden.
mit serial.read sehe ich die STX und auch die Reaktionen auf ein DLE.

Die Module c3964r.py, schritte.py und logamatic.py habe ich angelegt, jetzt hapert es aber am
python-know how um weiterzukommen.

Kannst du mir etwas auf die Sprünge helfen um diese "menschenlesbare" Betriebs-Parmaterliste zu erhalten ?
Gruß
Ötzi

[oetzi]

Servus Black!
Meiner Logamatic2107 habe ein KM271 verpasst und mit RS232 des Raspi verbunden.
mit serial.read sehe ich die STX und auch die Reaktionen auf ein DLE.

Die Module c3964r.py, schritte.py und logamatic.py habe ich angelegt, jetzt hapert es aber am
python-know how um weiterzukommen.

Kannst du mir etwas auf die Sprünge helfen um diese "menschenlesbare" Betriebs-Parmaterliste zu erhalten ?
Gruß
Ötzi

mit dem testcode sieht die Kommunikation eigentlich schon ganz gut aus.

Code: Alles auswählen

pi@raspi:~/logo2107 $ more marc.py
import serial

s = serial.Serial(port = '/dev/ttyAMA0',
                  baudrate = 2400)
                  #timeout=5.0)

post=False
print (s.name )

#0xEE 0x00 0x00 0x10 0x03 0xFD
s.flushInput ()
s.flushOutput ()
s.write (b"\x02")
print("------> STX")
while True:
    if s.inWaiting ():
        char= s.read ()
        if len (char):
            print ("<--- %3.2X"% ord (char),)
            if ord (char)== 0x10:
                s.write (b"\xEE\x00\x00\x10\x03\xFD")
                print ("------> Kommando EE 00 00 10 03 FD")
                post=True
            elif ord (char)== 0x02:
                if post:
                    s.write (b"\x10")
                    print ("------> DLE")
            elif not post:
                s.write (b"\x02")
                print ( "------> STX")

pi@raspi:~/logo2107 $

das ist der Output des modifizierten script

Code: Alles auswählen

pi@raspi:~/logo2107 $ python marc.py
/dev/ttyAMA0
------> STX
<---  10
------> Kommando EE 00 00 10 03 FD
<---  10
------> Kommando EE 00 00 10 03 FD
<---  02
------> DLE
<---  04
<---  00
<---  07
<---  01
<---  C4
<---  4F
<---  C1
<---  26
<---  10
------> Kommando EE 00 00 10 03 FD
<---  03
<---  7D
<---  02
------> DLE
<---  02
------> DLE
<---  04
<---  00
<---  07
<---  01
<---  C4
<---  4F
<---  C1
<---  26
<---  10
------> Kommando EE 00 00 10 03 FD
<---  03
<---  7D
<---  02
------> DLE
<---  02
------> DLE
<---  04
<---  00
<---  07
<---  01
<---  C4
<---  4F
<---  C1
<---  26
<---  10
------> Kommando EE 00 00 10 03 FD
<---  03
<---  7D
<---  02
------> DLE
<---  02
------> DLE
<---  04
<---  00
<---  07
<---  01
<---  C4
<---  4F
<---  C1
<---  26
<---  10
------> Kommando EE 00 00 10 03 FD
<---  03
<---  7D
<---  02
------> DLE
^CTraceback (most recent call last):
  File "marc.py", line 16, in <module>
    if s.inWaiting ():
KeyboardInterrupt

hier komme ich nicht weiter.....
Gruß
Ötzi

[Black]

Hi, das ganze ist nicht grade Plau and Play und auch nicht gerade trivial.

du musst dir noch eine Klasse definieren

Code: Alles auswählen

class logamatic2107 (c3964r.Dust3964r,threading.Thread):
    message = True
    timeout = False
    # Array für die Betriebsstunden
    #[0]= minuten
    #[1]= minuten * 256
    #[2]= minuten * 65536
    aHour   = [0,0,0]

dort müssen folgende Methoden für die Klasse logamatic2107 noch angelegt werden

Code: Alles auswählen

    # Installations Konstruktor für den Treiber und für die Threads
    def __init__ (self):
        self.timeout = False
        c3964r.Dust3964r.__init__ (self,port='/dev/ttyAMA0',baudrate=2400,SLP=0.1,PRIO=self.HIPRIO)
        threading.Thread.__init__ (self)
        self.TimeStampMessage= t.time()

es braucht die eigentliche Run routine, sie wird abgebroche, wenn globale variable ende= true
ich weiss es geht auch eleganter, das tuts aber

Code: Alles auswählen

    # Das hier ist die eigentliche Routine die vom Thread aufgerufen wird
    def run (self):
        global ende
        while not ende:
            t.sleep (0.1)
            # Test auf Message TimeOut
            self.timeout= (t.time () - self.TimeStampMessage)>20
            self.running ()
        log ("error", "Logamatic Thread closed")  

dann gibts die Child Methoden ReadSuccess, ReadFail, WriteSuccess und WriteFail.
diese müssen überladen werden, damit die Childs die richtigen Methoden aufrufen

Mein beistpiel für Writesuccess, kannst du aber nur als Ansatz nehmen, da das gateway ziemlich in IOBroker und die CCU eingewoben ist

Code: Alles auswählen

    def WriteSuccess (self,telegram):
        global LCDmode
        global lcd
        if self.message:
            # Hier analysieren wir für den Debugger das Telegram
            if telegram==b"\xEE\x00\x00": # Logmode.
                log ("error","CMD: LOGMODE eingeleitet")
                lcd.lcd_clear ()
                lcd.lcd_print ("LOGMODE IST eingeleitet",1,1)
                LCDmode=1
            elif re.search (b"\x0c\x07eee.ee",telegram,re.S):
                log ("warning","CMD: WarmwasserSW auf " + str (telegram [5]) + " °C")
                CFG_WWtemp.setValuePrio (float (telegram [5]))          # Offset 7E:3
                pushState ('dom.GetObject ("KS_WWB_CONFTEMP").State (' + str (telegram [5]) +')' )
                pushIObroker ( [("L2107.WWB.CFG-BOILER",str (telegram [5])) ])  

Dass WriteFail, wenn das Schreiben an die 2107 mit Fehler abgebrochen wurde

Code: Alles auswählen

    def WriteFail (self,telegram):
        log ("error","SENDEJOB NICHT ERFOLGREICH ABGEBROCHEN")
        #logging.error ("SENDEJOB %s NICHT ERFOLGREICH ABGEBROCHEN", telegram)       
        pass

Das ist ein Beispiel für Readsucess, erfolgreiches lesen und Auswerten des Telegramms

Code: Alles auswählen

    def ReadSuccess (self,telegram):
        global LCDmode
        global FirstReady
        GPIO.output (GPIO_LED5,not (GPIO.input (GPIO_LED5)))
        # Wechseln von 0 1 in nach IOBroker schreiben.
        pushIObroker ([("L2107.LOG_TELEGRAM",str (GPIO.input (GPIO_LED5)) )])
        self.TimeStampMessage= t.time()
        if len (telegram)==8: # Wenn dann sind das die Konfigurationstelegramme
            if telegram [0]==0:  # Das ist der Nuller Block der Telegramme
                ID=telegram [1]
                if ID==0x00: # Der erste 6er Block kennung 00 00
                    # Hier kann der Block nun Ausgewertet werden
                    CFG_SommerAb.setValuePrio (telegram [3])                # Offset 00:1
                    CFG_TagTempHK1.setValuePrio (float (telegram [5])/2)    # Offset 00:2
                    CFG_NachtTempHK1.setValuePrio (float (telegram [4])/2)  # Offset 00:3
                    CFG_ModeHK1.setValuePrio (telegram [6])                 # Offset 00:4
                    stateVal= "{p:0.1f}".format (p=CFG_ModeHK1.getValue ())
                    s_push  = 'dom.GetObject ("KS_IW_STATUS").State (' + str (CFG_ModeHK1.getValue () ) +')'
                    s_push += 'dom.GetObject ("KS_STAT_SOMMER_AB").State (' + str (telegram [3]) +')'
                    s_log=""
                    if ENLogCCU:
                        s_log   = 'dom.GetObject("CUxD.CUX2801001:1.LOGIT").State("KS_STATUS;' + str (CFG_ModeHK1.getValue ()) + '")'
                    pushState (s_push + s_log)
                    #print (telegram [6])
                    pushIObroker ( [("L2107.HK1.CFGMODE_HK1", telegram [6])] )
                    pushIObroker ( [("L2107.HK1.STATUS_HK1", telegram [6])] )
                    pushIObroker ( [("L2107.KESSEL.CONFIG_SOMMER", telegram [3])] )
                    pushIObroker ( [("L2107.HK1.CFG_TAG", "{p:0.1f}".format (p=CFG_TagTempHK1.getValue () ))])
                    pushIObroker ( [("L2107.HK1.CFG_NACHT", "{p:0.1f}".format (p=CFG_NachtTempHK1.getValue () ))])
                    
                    #pushIObroker ([("L2107.HK1.CFG_TAG"  ,"{p:0.1f}".format (p=CFG_TagTempHK1.getValue ()) ),
                    #               ("L2107.HK1.CFG_NACHT","{p:0.1f}".format (p=CFG_NachtTempHK1.getValue ()) ),
                                   #("L2107.HK1.CFGMODE_HK1",str (CFG_ModeHK1.getValue ()) ),
                    #               ("L2107.HK1.CFGMODE_HK1",str (telegram [6]) ),
                    #               ("L2107.HK1.STATUS_HK1",str (telegram [6]) ),
                    #               ("L2107.KESSEL.CONFIG_SOMMER", str (telegram [3] ))
                    #             ])

Im Hauptprogramm wird das dann so aufgerufen:

Code: Alles auswählen

a=logamatic2107 ()
a.CFG_PRINT=False  # Einzeltelegramm Hex DEBUG Aus
a.newJob (b"\xee\x00\x00")
if not ENLogCCU:
    pushState ('dom.GetObject ("KS_LOG_Logamatik").State ("CCU Logging abgeschaltet")'  )
#a.telegrammOut= b"\xee\x00\x00"
# Telegramm HK1 Auto
#a.telegrammOut= b"\x07\x00\x65\x13\x65\x65\x02\x65"
# Telegramm Warmwasser auf 40 Grad
#a.telegrammOut= b"\x0C\x07\x65\x65\x65\x2A\x65\x65"
#a.telegrammOut=b""
#a.telegrammOut.append (b"\xee\x00\x00")
#a.RS232.buffer= b'\x66\x69\x10\x10\x02'
a.RealRun= True
a.start ()

Ich hoffe mit dem Ansatz kommste erstmal wieder was weiter.
Komplett fwürde das Progg mehr verwirrung stiften denke ich, weil da auch noch die LCD ansteuerung, die Auswertung der Taster und der Hardwaremäßigen Brennerrelais
sowie Webserver und Weather thread und bisschen regelung noch dranhängen.

greetz und viel Erfolg, Black

[grosseruser]

Hi,

vielen Dank Black, für dein Projekt und die Doku, die du bisher gemacht hast. Ich habe bisher leider noch kein Buderus KM271 Kommunikationsmodul. Auf den Bildern kann man aber erkennen dass dort eigentlich nur ein LT1281ACSW verbaut ist, der funktional einem MAX323(2) entspricht. Also anscheinend einen 5V TTL Pegel auf RS232 wandelt. Daran soll dann wieder ein MAX232 damit man wieder einen (3,3V) TTL Pegel für den Raspberry hat? Das und die 120 Euro die für die KM271 aufgerufen werden möchte ich mir gerne sparen. Leider reichen mir die Aktuell von Google gefundenen Bilder nicht für ein Reverse Engineering, da du erwähnt hast, dass die Platine schon nach dem einfachen einstecken erkannt wird. Die Platine ist mit 8 von 12 Pins angeschlossen, zieht man 2 Pins für VCC und GND, zwei Pins für den Abgasfühler (für mich schon einer zu viel) und für RX + TX ab bleiben zwei über die mit der Platinenerkennung zu tun haben könnten.

Jetzt meine Bitte, kann jemand die KM271 Platine ausreichend Hochauflösend und ohne Leiterbahn verdeckende Aufkleber Fotografieren, so dass man die Schaltung nachvollziehen kann? Vor allem der Wert von R3 währe Wichtig.

Auf den Bilder kann ich bisher folgendes erkennen. Wenn ich bei dem GND Pin von KL3 anfange und umlaufend zähle erhalte ich
01 GND
02 ? (Vermutlich Temperaturfühler geht in Richtung KL2)
03 RX oder TX (geht in Richtung LT1281)
04 ? beim FM241 4700 Ohm (Vermutlich Platinenerkennung mit Widerstand R3 an Pin 11)
05 NC
06 NC
07 NC
08 NC
09 ? (Vermutlich Temperaturfühler über Widerstand R2 an Pin 01 von KL2)
10 RX oder TX (geht in Richtung LT1281)
11 5,2 V gemessen am 28.10.2017 ( geht über Widerstand R3 an Pin 04, geht zu KL2 )
12 5,2 V gemessen am 28.10.2017 (Vermutlich 5V VCC scheint über Rückseite zum LT1281 zu gehen. Das GND Signal vom LT1281 ist auf der Vorderseite in diese Richtung an einen Kondensator geführt)

Ziel ist es einen ESP8266 über einen Pegelwandler anzuschließen. Dieser sollte in der Lage sein die Aufgaben des Raspis zu übernehmen und per WLAN mit ioBroker/MQTT zu kommunizieren. Die Konvertierung der Python Skripte nach C++ wird aber eine Herausforderung. Weboberfläche auf dem ESP und ein Display sind eher nth.

[grosseruser]

Ich habe mir mal einen Adapter gebastelt:



Leider weiß ich immer noch nicht welchen wert der Wiederstand für die Platinenerkennung haben muss. Der versuchsweise verwendete 10 kOhm Wiederstand führte zu einem FM242 Fehler wird also anscheinend vom FM242 Modul verwendet. Auf dem FM241 Modul ist ein 4,7 kOhm Wiederstand verbaut. Ich bin also weiter darauf angewiesen, das jemand auf seiner KM271 Karte den Wert von R3 abliest oder ich muss weitermachen mit Versuch und Irrtum

[Black]

ich würde jetz nur ungerne meine steuerung ausienanderschrauben und zerlegen.

hier mal ein link ins Mikrovontroller forum

https://www.mikrocontroller.net/topic/141831?page=1

die hatten seinerzeit nen funktionierenden nachbau erstellt, zumindest tats die schnittstelle, nur der abgasfühler nicht

Gruss, Black

[grosseruser]

Danke!

Es hat zwar zwei Abende gekostet, das Forum durchzulesen und aufzubereiten aber die Gesuchte und viele weitere Informationen (Buderusprotokoll) haben sich da gefunden. Der Wiederstandswert wurde auch da nur geraten, funktioniert aber. Mein Adapter braucht etwa 100 mA und sollte laut Forum Probleme machen. Die Versorgungsspannung fällt auch wirklich von 5,18 auf 4,88 Volt aber die Temperaturen am Display der Logomatic verändern sich nicht, so dass die Hardware vorerst steht. Auf eine MicroSD Karte (oder gar ein Display) direkt am Adapter werde ich aber verzichten. Jetzt kommt der Teil, den ich weniger mag, die Software. Zum Glück lassen sich die ESP8266 per WLAN Flashen, so dass ich dafür nicht im Keller sitzen muss.

Gruß,
Martin

[Black]

ich täte aber einplanen, das du die Meldungen Brenner Betrieb und Brenner Störung direkt vom Feuerungsautomaten mit Relais abkoppelst.

Grund:
Die Logamatik gibt Brenner betrieb raus, wenn die dem Feuerungsautomaten den Befehl brenner Start gibt. Das heisst aber noch nicht, das de brenner an ist bzw auch an gehen wird:

Grund 1:
Bei Ölheizung startet der Feuerungsautomat erstmal die Sequenz: Öl vorwärmen, erst dann kommt gebläse an, danach Zündfunke und dann öl einspritzen. richtig in Betrieb ist der brenner erst, wenn die Flammüberwachung des FA Flammrückmeldung gibt
Bei Ölbrennern entsteht so eine Differenz zwischen realer Laufzeit und der Laufzeit der Logamatik. dafür lässt sich aus der Laufzeit bei Ölbrennern bei bekannter Düse/Vordruck auf dem Verbrauch an l/h rechnen.
Grund 2:
Die Logamatik bekommt nicht mit, wenn aus irgendwelchen Gründen der Brenner nicht eingehen wird (Stichwort externe Sicherheitskette, hier meinstens Pmin eingeschliffen).
Aus dem grunde dann Softwaretechnisch generieren, wenn innerhalb bestimmter zeit nach Brenner Startbefehl Logamatik nicht die relaisrückmeldung FA kommt, dann stimmt was nicht.

3: Flammabriss bekommt die logamatik in Standartverdrahtung nicht als störung mit, der FA geht zwar vorschriftsmäßig in Störung und schaltet gebläse und einspritzpumpe ab.
Wenn es allerding bei brennerstart passiert, bekommt es die Logamatic nicht mit, da sie noch davon ausgeht, das der brenner noch vorwärmt.

So erlebt bei verschlissener Zündelektrode, die morgens bei kaltem brenner nicht zuverlässig zündete udn dann Softwaremäßig 4 Stunden Betrieb anstanden, (klar, die Logamatic gibt in der Zeit auch Brenner Start als Kommando aus), der FA abber in Flammabriss gegangen ist.

also wenn du dir die mühe machst, da eine vernünftige Elektronik zu entwerfen, würde ich diese Fälle mit einplanen. Das war auch meine erste Revision, die ich nachgerüstet hatte, die ursprunsgplanung und Rev A Ausführung von mir hatte das auch nocht nicht



das sind die Signale B4 (Klemme = betrieb und S3 (Klemme 9 = Störung) Am Brennerstecker oben. Potentialbehaftet 230V gegen N, also Vorsicht.

Gruss, Black