Buderus Logamatic 2107 Revision 3 2019

[Black]

Mit erschrecken hatte ich festgestellt, das auf dem Gateway immer noch ein Raspbian Sqeeze läuft und ich das gute Stück das letzte mal im April 2017 gebootet hatte...

eigentlich halb so gross das Problem, die entsprechenden Python Files liegen auf dem Server als Backup... alles gut.
aber beim versuch letztens, eine Python erweiterung einzuspielen, die ich für geplante MQTT Änderungen brauchte, sagte er mir doch glatt, Ätsch, nicht mit dem Betriebssystem.

Ok, ich werd den Teufel tun, ein Upgrade über 3 Betriebssystemversion in laufendem Betrieb in der Heizperiode zu machen.

Also stand als Planung an:

Neuer Pi
Vernünftiger RS232 Wandler (der alte tats über 3 Jahre, war aber Gefriemels)
Status LEDs und Anschlussmöglcihkeit für die Relais, Taster direkt auf der Huckepackplatine
MQTT Client anbindung an MQTT Server (iobroker spielt den Broker)
Autarker Web Server
1wire Interface
immer noch mein 4x40 LCD Display, diesmal amler vernünftig als I2C angebunden mit pgelwandlern.

die geplanten Features tuns mittlerweile
(wobei, bis ein Stretch soweit war, funktionieren zu wollen, was die RS232 auf TTYAMA0 angeht, da hatte sich in den letzten Betriebssystemversionen einiges geändert. die damaligen Notizen waren da für den .....)
den MQTT client krieg ich nun über callback ohne exception gestartet, wenn mein switch oder der IOBroker nach Powerdown noch nicht oben sind
Auto reconnect klappt auch bei Broker down oder Line down
web server kommt er alte rein
die logamatic class kommt auch die alte rein, die tats ja mehrere jahre
Huckepack Platine besorgt als pegelwandler RS232 und noch bisschen draufgelötet levelshifter i2C und status LED´s / taster
4*40 LCD auf I2c umgebaut
1 Wire Interface
python testroutinen für das 40x4 unter i2c geschrieben

vllt schreib ich teile dvon nu auch in lazarus, ich wollte eh mal probieren, Lazarus auf ein linux zu portieren. Gab ja nicht wenige, die mich gefragt hatten, ob ich den SDV auch in einer Linux version bringen.

Der Pi mit dem fertigen Huckepackaufbau:

Display mit i2C Wandler
für ein 40x4 gibts die serienmäßig nicht von der Stange

Anzeige geht

das kann ich in Ruhe auf dem Schreibtisch ausprobieren und programmieren, bevor ich dann das fertige Teil nach Ende der Heizperiode gegen das alte Stück austausche. Im Iobroker muss ja auch noch einiges geändert werden.
Aber auch die CCU könnte ja dann als MQTT client die Daten des kessels mithören oder auch drin eingreifen. aber das weiss ich noch nicht. sollte aber als Abfallprodukt auch funktioren.

Black

(der nun bei dem schönen Wetter mit den Hunden spazieren geht)

[Black]

Eine vllt interessante Erweiterung für die Kollegen, die dieses Gateway bei sich nachgebaut haben.

mit folgender Erweiterung ist es möglich den Fehlerspeicher der L2107 auszulesen und auch in den IOBroker zu bekommen.

Als erstes Unter IOBroker 4 Stringvariablen anlegen in dem Javascript Adapter, in das das Gateway auch die Werte schreibt:

Code: Alles auswählen

{
  "from": "system.adapter.admin.0",
  "ts": 1552564889357,
  "common": {
    "name": "ALARM1",
    "role": "",
    "type": "string",
    "desc": "Manuell erzeugt",
    "def": "",
    "read": true,
    "write": true
  },
  "native": {},
  "acl": {
    "object": 1636,
    "owner": "system.user.admin",
    "ownerGroup": "system.group.administrator",
    "state": 1636
  },
  "_id": "javascript.0.L2107.KESSEL.ALARM1",
  "type": "state"
}

Als nächstes auf dem Gateway die Python files Sichern !! wichtig

dann in dem program l2107.py die procedure readsucess der class logamatic2107 so anpassen:
in python üblich immer brav an die EINRÜCKUNGEN ACHTEN !!!

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

###############
### Das hier kommt neu hinzu

        if len (telegram)==9: # Wenn dann sind das die fehlerspeicher
            if telegram [0]==3:  # Das ist der Dreier Block der Telegramme
                ID=telegram [1]
                if ID==0x00: # Der erste 6er Block kennung 03 00
                    pushIObroker ( [("L2107.KESSEL.ALARM1",str (telegram [2])+","+str (telegram [3])+","+str (telegram [4])+","+str (telegram [5])+","+ str (telegram [6])+","+str (telegram [7])+","+str (telegram [8]) ) ])
                elif ID==0x07: # Der zweite 6er Block kennung 03 07
                    pushIObroker ( [("L2107.KESSEL.ALARM2",str (telegram [2])+","+str (telegram [3])+","+str (telegram [4])+","+str (telegram [5])+","+ str (telegram [6])+","+str (telegram [7])+","+str (telegram [8]) ) ])
                elif ID==0x0E: # Der dritte 6er Block kennung 03 0E
                    pushIObroker ( [("L2107.KESSEL.ALARM3",str (telegram [2])+","+str (telegram [3])+","+str (telegram [4])+","+str (telegram [5])+","+ str (telegram [6])+","+str (telegram [7])+","+str (telegram [8]) ) ])
                elif ID==0x15: # Der dritte 6er Block kennung 03 15
                    pushIObroker ( [("L2107.KESSEL.ALARM4",str (telegram [2])+","+str (telegram [3])+","+str (telegram [4])+","+str (telegram [5])+","+ str (telegram [6])+","+str (telegram [7])+","+str (telegram [8]) ) ])          

##### bis hierhini den text hinzu
##############################

        if len (telegram)==8: # Wenn dann sind das die Konfigurationstelegramme
            if telegram [0]==0:  # Das ist der Nuller Block der Telegramme

Wenn l2107.py dann geändert ist, im Webserver das Kill Komando ausführen und reboot




es landen 4 String im IOBroker mit folgendem Aufbau
byte 0: Error Code
0 = "Kein Fehler",
2 = "Aussenfuehler defekt",
3 = "HK1-Vorlauffuehler defekt",
4 = "HK2-Vorlauffuehler defekt",
8 = "Warmwasserfuehler defekt",
9 = "Warmwasser bleibt kalt",
10 = "Stoerung thermische Desinfektion",
11 = "HK1-Fernbedienung defekt",
12 = "HK2-Fernbedienung defekt",
15 = "Keine Kommunikation mit HK1-Fernbedienung",
16 = "Keine Kommunikation mit HK2-Fernbedienung",
20 = "Stoerung Brenner 1",
24 = "Keine Verbindung mit Kessel 1",
30 = "Interner Fehler Nr. 1",
31 = "Interner Fehler Nr. 2",
32 = "Interner Fehler Nr. 3",
33 = "Interner Fehler Nr. 4",
49 = "Kesselvorlauffuehler defekt",
50 = "Kesselzusatzfuehler defekt",
51 = "Kessel bleibt kalt",
52 = "Stoerung Brenner",
53 = "Stoerung Sicherheitskette",
54 = "Externe Stoerung Kessel",
55 = "Abgasfuehler defekt",
56 = "Abgasgrenze ueberschritten",
87 = "Ruecklauffuehler defekt",
92 = "RESET"

byte 1: Stunde wo der Fehler auftrat
byte 2: minute wo der Fehler auftrat
byte 3: vor x tagen aufgetreten **1
byte 4: stunde wo quittiert wurde (0xFF - fehler nicht quittiert sondern steht noch an)
byte 5: minute wo quittiert
byte 6: vor x tagen quittiert

**1 wenn noch nicht quittiert (byte4=0xFF) dann bedeutet : vor x tagen aufgetreten
wenn quittiert, aufgetreten berechnet sich aus byte3+byte6

Auswertung dann in IOBroker, string zerlegen und in die eigene Vis nach belieben einbauen

Gruss, Black

die Rev3 wird den kompletten bekannten Datenbereich der l2107 abbilden, ankopplung dann allgemeingültig über MQTT

[Flo27]

Guten Abend,

ich bin auch gerade dabei, meine Heizung über MQTT an iOBroker anzubinden.
Bist Du mit Deiner Anbindung weitergekommen? Den Ansatz mit dem Webserver finde ich auch sehr interessant als Backup-Zugriffsweg.
Wäre es möglich Einblick in Deinen Quellcode zu bekommen?

Vielen Dank und Grüße
Flo

[Black]

hi, ich habe eine laufende Anbindung, die stammt aber noch aus dem Jahre 2015 und die wollte ich mal renovieren... Debian strech u.a. und mqtt wollte ich auch reinbauen.

die grundsachen tuns, wegen heizperiode hab ichs mir aber verkniffen am produktivsystem zu basteln... Aus demgrunde hab ich eine kleine prioritätsverschiebung zugunsten meínes SDV projektes gehabt.

Über den Sommer werd ich das zu ende bringen , denke ich, bin mir aber noch nicht schlüssig, ob ichs wieder auf dem PI mache oder, na mittlerweile mein Server NUC samt USV da unten steht, direkt aus Python Script auf dem NUC. USB Passthrough über proxmox ging, den Kurzverbindungscheck zur Logamatik von dem NUC aus hab ich probiert gehabt.

Black

[Flo123]

Hi, danke für die schnelle Antwort.
Schade, dachte ich könnte da evtl. auf was bestehendes aufsetzen. Insbesondere was das Codieren/Dekodieren der Telegramme angeht.

[Black]

bei dem codierverfahren kann ich dir helfen, die Codetables habe ich mittlerweile (Ausnahmen sind der Solarregler, den hab weder ich noch jemand den ich kenn, so konnt ich mir die Telegrame auch nicht reverse angucken und die Timergeschichte.

Ich weiss zwar wie es geht, aber der Nutzen die über die API anpassbar zu machen steht bei mir nicht im Verhältnis zum Aufwand. die Auswahl des fertigen Programmstyp eigen ist dagegen selbstverständlich.

letztlich isses immer eine handcrafted customized angelegenheit.

Auch ich trau mich net, ohne zwingenden Grund unten das alte OS upzugraden. Um den Nachfolger nu zu testen, hab ich im alten Programm eine Python erweiterung zu geschrieben, die mir via socket das raw RS232 telegram als hex in iobroker schreibt, der IObroker dieses nach MQTT kopiert und das Subscribe simuliert in die ttyAma0 des neuen rechners eingeschleust wird und dann von dem neuen Programm verarbeitet wird und wieder via MQTT an IObroker geht. so kann ich das neue validieren ohne das alte auszubauen und trotzdem über den Umweg an der realen L2107 schnittstelle zu hängen. bevor die Nachfrage kommt, unten auf dem Pi das os ist so alt, dass sich paho-mqtt nicht installieren lässt ^^, drum der socket umweg über iobroker

nicht ganz einfach das. aber dafür gibts dann hoffentlich am Ende eine saubere in classen gekappselte Umsetzung. in der alten Version finden sich noch Erstlingswerke von mir was das ThreatHandling angeht und auch noch einwebungen zur CCU kommunikaton, die ich seit 2016 nicht mehr habe

Black

[gewuerzgurke84]

Hallo zusammen,

ich stehe aktuell auch vor der Herausforderung meiner Buderus Ölheizung einige Daten zu Optimierungszwecken zu entlocken und verwende üblicherweise Openhab in Kombination mit InfluxDB/Grafana zur Speicherung+Darstellung von Messwerten.

Gibt es an irgendeiner Stelle eigentlich "den letzten" Stand des Quellcodes für das Auslesen der Daten aus dem KM271-Modul?

Ich würde gerne versuchen zu verstehen was da genau passiert und ggfls. ein Openhab-Modul hierfür anzufertigen.
Erkannt habe ich das es einen Python-Treiber gibt, der das grundlegende Protokoll implementiert: http://www.foto-paintings.de/index.php/ ... ng/16-test

Alles weitere scheint mir irgendwie verstreut zu sein oder ich bin zu blind

Liebe Grüße

[Black]

yap, das ist verstreut und da es gewachsen ist und einen umzug der logik von der CCU auf IObroker mitgemacht hat, nicht so ganz einfach zu trennen.

Die MQTT version hab ich zwar im Teststand laufen und die läuft auch parallel zur alten Steuerug mit, sendet aber nicht aktiv.

Aber das projekt ist etwas in den Hintergrund gerückt. Dazu müsste ich mich mal dazu durchringen, an einem ruhigen Wochenende so um die 500 Zeile Programmcode in IObroker umzuschreiben vom SimpleApi Handling auf MQTT. Heisst das ganze doppelt die erste zeit.

Und bis dato scheiterte es bis dahin noch an der Zeit für diese Portierung.

Black

[gewuerzgurke84]

Mit der MQTT-Version ist eine Version gemeint, die die Betriebs- und Konfigurationsdaten an einen MQTT-Broker weitergibt?

Falls ja, wo finde ich den Quellcode hierzu? Wenn die Daten in einem MQTT-Broker abgreifbar wären, dann wäre dies sicherlich ein großer Mehrwert ungeachtet der genutzten Heimautomatisierungs-Software

Danke & LG

[Black]

das ist der Part, der noch nicht final fertig ist. das dies die Scnittstelle allgemeingültig macht weiss ich, ist ja das interessante.