Buderus Logamatic 2107 Revision 3 2019

User stellen ihre Haussteuerung vor

Moderator: Co-Administratoren

Benutzeravatar
Black
Beiträge: 4135
Registriert: 12.09.2015, 22:31
System: Alternative CCU (auf Basis OCCU)
Wohnort: Wegberg
Hat sich bedankt: 153 Mal
Danksagung erhalten: 535 Mal
Kontaktdaten:

Buderus Logamatic 2107 Revision 3 2019

Beitrag von Black » 02.10.2015, 20:49

:P <<--- das ist jeniger Smiliy

In meinem Haus werkelt eine Homematic CCU2, diverse Aktoren und Sensoren. Ersteinmal Zwecks Analyse bestannd bei mir der Wunsch, die Daten meiner Heizung (2107M) auch mit in die Homematic zu bekommen, um dort via HighChart etc Auswertungen machen zu wollen.
Aber wie. Ein Kabel von der CCU2 in Richtung Heizungskeller liegt nicht, alles über funk, irrwitzig teuer. WLAN auf RS485 Gateway, intabil, neigt zu häufigen aussetzern.

Also entstand der Gedanke, unten einen RaspPI zu installieren, diesen ins WLAN zu integrieren, auf der CCU2 werden CUXD geräte für die Temperaturen und Schaltzustände angelegt. Auf den PI läuft dann ein Python Script, welches die Werte über HTTP - Post auf Port 8181 als HM-Script in die CCU2 überträgt.
Bei einem PI bietet sich ja quasi als Tempfühler schon die DS18B20 an, 1 Wire, der Pi bringt das in seinen Kernel Modulen direkt mit (GPIO4).

dazu kommt dann noch , wenn schon, denn schon, 40*4 LCD Display am PI, um Vor ort die Werte auch ablesen zu können sowei die Möglichkeit von 8 Digitalen ein und 8 Digitalen ausgängen (Pumpen Zustand einlesen bzw Pumpen Schalten (als Zukunftsprojekt))

Tempfühler:
VL-Temp (DS18B20): Installiert: OK - Funktion RaspPI OK - Funktion CCU2 OK
RL-Temp (DS18B20): Installiert: OK - Funktion RaspPI OK - Funktion CCU2 OK
WW-Temp (DS18B20): Installiert: OK - Funktion RaspPI OK - Funktion CCU2 OK
RL_WW_Temp (DS18B20): Installiert: OK - Funktion RaspPI OK - Funktion CCU2 OK

WWB Temp und KesselTemp: DS18B20 Canceld, Lösungsansatz 2 wird probiert, funktionierte zwar, aber 2. Ansatz ist elekanter als gerade beim Boiler drangepappter Fühler

DISPLAY: In Vorbereitung, SW erstellung Python steht noch aus

Mittlerweile kritallisierte noch eine weitere Möglichkeit aus, an der ich aktuell am arbeiten bin: die Buderus 2107M lässt sich über ein KM271 Modul an serieller Schnittstelle auslesen und auch steuern. Laut Unterlagen Buderus geschieht dies über das 3964r Protokoll als Layer 2 auf der RS232. da musste der alte SPS Programmierer ein bisschen lächeln, 3964r bzw RK512 wren noch vor einiger Zeit DAS handwerkszeuch beim Koppeln von SPSen auf Industrieebene. Und irgendwo in meinen alten unterlagen aufm Speicher fand sich noch ein Flussdiagramm des protokolls. Augenblicklicher Status:
Kopplung RaspPI übe eine Norm RS232 an KM271: OK, physikalischer Layer steht, die Spielerei mit STX <--> DLE tuts schon, ok, dann kommt noch nix von mir, also folgt nach QVZ ein NAK.. kommt aber noch

proggen des 3964r Protokolls samt seiner Exceptions in Python: Immo in Arbeit, tests auf Lap mit Phyton , realtests mit Raspberry

Durchspielen der telegramme mit der 2107M : ausstehend

Integriegen in Hauptscript auf dem RaspPI: ausstehend

damit ergeben sich dann die Werte:
kesselTemp, Boilertemp, Aussentemp und gedämpfte Aussentemp aus der Steuerung sowie RaumTemp1 SW & IW.

ebenso alle Zustände der Pumpen und des kessels.

Steuernd lassen sich die zeiten, der Zustand: auto, Tag und Absenk sowei WW SW setzen (haben leute schon mit nem Mikrokontroller geschafft, muss also mit nem python script auch gehen)

und das ganze dann in vernünftig zusammengebaut, immo is das noch Labor Lochraster aufbau.

und wenn der RaspPi eh einmal in Dauerbedtrieb läuft ,dann kann er auch gleich als reverse Proxi den Zugriff von aussen auf die Anlage organisieren. Also, einiges Tuts schon geprüft, einiges in grundlagen, ein paar dinge müssen noch.

to be continued

Black
Zuletzt geändert von Black am 17.02.2019, 13:25, insgesamt 4-mal geändert.
Wenn das Fernsehprogramm immer mehr durch nervende Werbung unterbrochen wird und der Radiomoderator nur noch Müll erzählt, ist es besser, die Zeit für sinnvolle Dinge zu nutzen - mal aufs Klo zu gehen, ein Bier zu holen oder einfach mal den roten AUS-Knopf zu drücken.
Klick - und weg

Script Time Scheduler V1.3
SDV 4.08.04A Das umfassende Entwicklungs und Diagnosetool für Homematik

technical contribution against annoying advertising

hermanthegerman2
Beiträge: 11
Registriert: 09.10.2015, 16:13

Re: Der Heizungskeller , RaspPI und CCU2

Beitrag von hermanthegerman2 » 09.10.2015, 16:27

Hallo Black,

cooles Projekt!
Hast Du die 3964R Routine schon fertig ? Könnte dir einen Codeschnipsel zur Verfügung stellen, bin allerdings in der Python Programmierung ein DAU !

Ich möchte ebenfalls meine Heizung Logamatic4000 Steuerung über das RS232-Gateway mit einem RaspberryPi verbinden und IP-Symcon als Visualisierungsprogramm (welches jetzt auch auf Raspberry lauffähig ist -> Betaphase)
www.symcon.de

Problem ist: Symcon bietet mir kein Protokoll mit 3964R als Modul an.
Könntest Du mir behilflich sein die Routine in Python zu schreiben, d.h. der Raspi empfängt von der Heizung auf Port 10000 ... interpretiert mit 3964R und gibt die Rohdaten an Port 10001 weiter. Das ganze sollte aber auch Bidirektional gehen.

Unterlagen für Buderus Heizungen und deren Kommunikation zum auslesen bzw. Parametrieren habe ich hier.

Wäre schön, wenn Du mir da weiterhelfen könntest.

Gruß,
Hermann

Benutzeravatar
Black
Beiträge: 4135
Registriert: 12.09.2015, 22:31
System: Alternative CCU (auf Basis OCCU)
Wohnort: Wegberg
Hat sich bedankt: 153 Mal
Danksagung erhalten: 535 Mal
Kontaktdaten:

Re: Der Heizungskeller , RaspPI und CCU2

Beitrag von Black » 10.10.2015, 18:50

Ich hab den Code der Routine schon soweit fertig, läuft aber nochin der Validierungsphase... das Dingen ist nämlich nicht so ganz ohne.

irgendwie hast du da aber einen kleinen Denkfehler bei dir. 3964r ist kein Codierungsverfahren, sondern eine Art Handshake, welches man im ISO Modell auf Schicht 2 betrachten kann.

ich hab mal bisschen Text dazu zusammengefasst:

http://foto-paintings.de/index.php/haus ... oll-3964-r

ich denk da eher, das du die Schnittstelle und der gleichen unter Python auf dem PI bedienen musst, die Daten dort auch aufbereitest und dann zu deiner übergeordneten Steuerung schickst. weil wenn IP Symcon das nicht abbildet, wird das auch kein Handshake mit deiner heizung hinbekommen.

Da ich letzte Woche mit meiner Frau in unserem hoffentlich wohlverdienten Urlaub war, kann ich erst jetzt wieder richtig weitermachen.

Gruss, Black
Wenn das Fernsehprogramm immer mehr durch nervende Werbung unterbrochen wird und der Radiomoderator nur noch Müll erzählt, ist es besser, die Zeit für sinnvolle Dinge zu nutzen - mal aufs Klo zu gehen, ein Bier zu holen oder einfach mal den roten AUS-Knopf zu drücken.
Klick - und weg

Script Time Scheduler V1.3
SDV 4.08.04A Das umfassende Entwicklungs und Diagnosetool für Homematik

technical contribution against annoying advertising

Benutzeravatar
Black
Beiträge: 4135
Registriert: 12.09.2015, 22:31
System: Alternative CCU (auf Basis OCCU)
Wohnort: Wegberg
Hat sich bedankt: 153 Mal
Danksagung erhalten: 535 Mal
Kontaktdaten:

Re: Der Heizungskeller , RaspPI und CCU2

Beitrag von Black » 10.10.2015, 19:53

so, das baby gibt schon Daten von sich... ich möcht edie Stabilität aber noch validieren.

Bild

ist eine hardcopy vom remote desktop des PI

der Treiber wurde im Debug mode gestartet, so das er alles mitschreibt, was auf der schnittstelle abgeht und wenn, welche exceptions erkannt wurden und die reaktion darauf. DLE-OK heist Telegramm wurde akzeptiert.
[RX] heisst, das das Telegramm von PI seite aus ein lesendes Telegramm war.
das r bzw s hinter den hexzahlen, ob diese zahl empfangen (r) oder gesendet (s) wude

Zu erkennen ist hier, das alles wirklich in einem lupenreinen 3964r Protokollrahmen läuft
Das Telegramm beginnt mit 02 (STX) von der Logamatic, dann antwortet der PI brav mit 10 (DLE) wodrauf die logamatic die Nutzdaten 80 00 04 und den Endframe des Protokolls mit 10 (DLE) 03 (STX) und 97 (BCC Checksum) sendet.
Der PI trennt den Frame wirder von den Nutzdaten, prüft die Checksum und sendet wenn alles OK, sein DLE damit ist der 3965r frame successful closed.

Das Nutztelegramm setzt sich dann so zusammen:

das Telegramm zeit in den untersten beiden Zeilen:
betriebswerte 1 (Telegrammkennung 80 00) und Betriebswerte 2 (Telegrammkennnung 80 01)vom HK 1 des Kessels
hier: Betreibswert 1 = 4
Betriebswert 2 = 2

Die 4 Bedeutet: Automatikbetrieb
Die 2 Bedeutet: Tagbetrieb

also, es geht also, muss aber nochwas getestet werden

Gruss, Black
Wenn das Fernsehprogramm immer mehr durch nervende Werbung unterbrochen wird und der Radiomoderator nur noch Müll erzählt, ist es besser, die Zeit für sinnvolle Dinge zu nutzen - mal aufs Klo zu gehen, ein Bier zu holen oder einfach mal den roten AUS-Knopf zu drücken.
Klick - und weg

Script Time Scheduler V1.3
SDV 4.08.04A Das umfassende Entwicklungs und Diagnosetool für Homematik

technical contribution against annoying advertising

hermanthegerman2
Beiträge: 11
Registriert: 09.10.2015, 16:13

Re: Der Heizungskeller , RaspPI und CCU2

Beitrag von hermanthegerman2 » 10.10.2015, 21:22

Hallo Black,

danke für die Antwort.

Ich denke ich habe Dich etwas mit meinen Port´s verwirrt.
Zur Vorgeschichte. Bis jetzt ist Symcon auf Windoof gelaufen. Darauf habe ich (wie in Deinem Link beschrieben) die Software ProtocolControlModul von der Firma LeaOil als 3964R-Interpreter laufen gehabt. Die Herren haben mir sogar eine kostenlose private Lizenz zukommen lassen.
Diese Software macht genau das, was ich in meinem ersten Post beschrieben habe.

Daten über einen Port (oder RS232)rein <-> 3964R (2. Schicht ISO-OSI Modell) <-> Daten über anderen Port raus (Symcon)
Das Ganze Bidirektional.

Da ich aber mit Symcon auf den Raspberry umgezogen bin benötige ich ein Programm, welches die 2. Schicht (3964R) oder DUST abbildet.
Mein RS232-Gateway der Logamatic kommuniziert aktuell mit ttyUSB0 des Raspberry´s. Wenn ich direkt auf diesen Port mit Symcon lausche bekomme ich die Hex 0x02 (STX).

An welche Schnittstelle oder Programm gibst Du die Daten Deines Skripts weiter ?

Sieht übrigens schon mal Klasse aus dein Screenshot !

Gruß,
Hermann

Benutzeravatar
Black
Beiträge: 4135
Registriert: 12.09.2015, 22:31
System: Alternative CCU (auf Basis OCCU)
Wohnort: Wegberg
Hat sich bedankt: 153 Mal
Danksagung erhalten: 535 Mal
Kontaktdaten:

Re: Der Heizungskeller , RaspPI und CCU2

Beitrag von Black » 10.10.2015, 21:43

also, so langsam wirds heller... ok, nu wirds klar wies bei dir lief.

leaoil die sachen sind schon gut, deren unterlgen hab ich ja auch benutzt, um das protokoll hinzustellen.

wenn du STX schon bekommst, ist deine schnittstelle ja schcon mal gesprächig.
pysikalischer layer tus ja schon

probier mal folgende kurzen codezeilen aus

Code: Alles auswählen

import serial

s = serial.Serial(port = 'ttyUSB0',
                  baudrate = 2400)
                  #timeout=5.0)

post=False
print (s.name )

#0xEE 0x00 0x00 0x10 0x03 0xFD
s.flushInput ()
s.flushOutput ()
s.write (b"\x02")
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")
                post=True
            elif ord (char)== 0x02:
                if post:
                    s.write (b"\x10")
            elif not post:
                s.write (b"\x02")


eventuell musst du die baudrate anpassen... (ich glaub, das gateway bei dir läuft auf 9600, musste bei dir nachgucken)

das ist eigentlich nur ein kleiner schnippel, bei der 2107 krieg ich die damit gesprächig, in dem ich sie in den logmode schalte und dann sendet die logamatic wild drauf los. heisst, auf ein STX der logamatic anwortet meine mit DLE, aber die Telegrammbestätigung geht so nicht. aber erstmal egal. wichtig wäre, das dein gäteway nach nem DLE schon mal sendet bzw ob man das noch in nen bestimmten modus schalten muss

ich hab bei mir eine ccu2 am laufen, entweder lege ich da systemvariablen an, oder CUxD Geräte, und von aussen kann ich über HTTP POST, wenn und ich in dem Post scritptext übergebe, diese Systemvariablen oder auch CUxD Geräte von aussen mit Werten versorgen. dieses Posting macht dann der PI.

Code: Alles auswählen

httpServ.request('POST', 'blabla.exe', 'dom.GetObject ("HZG_VL_HZG:1").DPByHssDP("SET_TEMPERATURE").State ("+VLTEMP+")')
Gruss. Black
Wenn das Fernsehprogramm immer mehr durch nervende Werbung unterbrochen wird und der Radiomoderator nur noch Müll erzählt, ist es besser, die Zeit für sinnvolle Dinge zu nutzen - mal aufs Klo zu gehen, ein Bier zu holen oder einfach mal den roten AUS-Knopf zu drücken.
Klick - und weg

Script Time Scheduler V1.3
SDV 4.08.04A Das umfassende Entwicklungs und Diagnosetool für Homematik

technical contribution against annoying advertising

hermanthegerman2
Beiträge: 11
Registriert: 09.10.2015, 16:13

Re: Der Heizungskeller , RaspPI und CCU2

Beitrag von hermanthegerman2 » 10.10.2015, 22:19

Hallo Black,

wie vermutet :-)

Code: Alles auswählen

root@ips:~# python 3964r.py
/dev/ttyUSB0
 10
 10
 02
 A6
 00
 00
 00
 00
 10
 03
 B5
 02
 02
 A6
 00
 00
 00
 00
 10
 03
 B5
 02
 02
 A6
 00
 00
 00
 00
 10
 03
 B5
 02
 02
 A6
 00
 00
 00
 00
 10
 03
 B5
 02
 02
 A6
 00
 00
 00
 00
 10
 03
 B5
 02
 02
 A6
 00
 00
 00
 00
 10
 03
 B5
 02
 02
 A6
 00
 00
 00
 00
 10
 03
 B5
 02
 02
 A6
 00
 00
 00
 00
 10
 03
 B5
 02
 02
 A6
 00
 00
 00
 00
 10
 03
 B5
 02
 02
 A6
 00
 00
 00
 00
 10
 03
 B5
 02
 02
 A6
 00
 00
 00
 00
 10
 03
 B5
 02
 02
 A6
 00
 00
 00
 00
 10
 03
 B5
 02
 02
 A6
 00
 00
 00
 00
 10
 03
 B5
 02
 02
 A6
 00
 00
 00
 00
 10
 03
 B5
 02
 02
 A6
 00
 00
 00
 00
 10
 03
 B5
 02
 02
 A6
 00
 00
 00
 00
 10
 03
 B5
 02
 02
 A6
 00
 00
 00
 00
 10
 03
 B5
 02
 02
 A6
 00
 00
 00
 00
 10
 03
 B5
 02
 02
 A6
 00
 00
 00
 00
 10
 03
 B5
 02
 02
 A6
 00
 00
 00
 00
 10
 03
 B5
 02
 02
 A6
 00
 00
 00
 00
 10
 03
 B5
 02
 02
 A6
 00
 00
 00
 00
 10
 03
 B5
 02
 02
 A6
 00
 00
 00
 00
 10
 03
 B5
 02
 02
 A6
 00
 00
 00
 00
 10
 03
 B5
 02
 02
 A6
 00
 00
 00
 00
 10
 03
 B5
 02
 02
 A6
 00
 00
 00
 00
 10
 03
 B5
 02
 02
 A6
 00
 00
 00
 00
 10
 03
 B5
 02
 02
 A6
 00
 00
 00
 00
 10
 03
 B5
 02
 02
 A6
 00
 00
 00
 00
 10
 03
 B5
 02
 02
 A6
 00
 00
 00
 00
 10
 03
 B5
 02
^CTraceback (most recent call last):
  File "3964r.py", line 14, in <module>
    if s.inWaiting ():
  File "/usr/lib/python2.7/dist-packages/serial/serialposix.py", line 431, in inWaiting
    s = fcntl.ioctl(self.fd, TIOCINQ, TIOCM_zero_str)
KeyboardInterrupt
root@ips:~#

Benutzeravatar
Black
Beiträge: 4135
Registriert: 12.09.2015, 22:31
System: Alternative CCU (auf Basis OCCU)
Wohnort: Wegberg
Hat sich bedankt: 153 Mal
Danksagung erhalten: 535 Mal
Kontaktdaten:

Re: Der Heizungskeller , RaspPI und CCU2

Beitrag von Black » 10.10.2015, 22:26

yap, auf jeden fall redet die ja dann schon mal munter vor sich hin... ist ja was
Wenn das Fernsehprogramm immer mehr durch nervende Werbung unterbrochen wird und der Radiomoderator nur noch Müll erzählt, ist es besser, die Zeit für sinnvolle Dinge zu nutzen - mal aufs Klo zu gehen, ein Bier zu holen oder einfach mal den roten AUS-Knopf zu drücken.
Klick - und weg

Script Time Scheduler V1.3
SDV 4.08.04A Das umfassende Entwicklungs und Diagnosetool für Homematik

technical contribution against annoying advertising

hermanthegerman2
Beiträge: 11
Registriert: 09.10.2015, 16:13

Re: Der Heizungskeller , RaspPI und CCU2

Beitrag von hermanthegerman2 » 10.10.2015, 22:46

Monitordaten muss ich wie folgt anfordern: ECOCAN-BUS-Adresse ist 00

Code: Alles auswählen

2.1 Anforderung der Monitordaten im „Direkt-Modus“
Mit dem Kommando ”0xA2 <ECOCAN-BUS-Adresse> ” können die Monitordaten des ausgewählten
ECOCAN-BUS-Gerätes von der Kommunikationskarte ausgelesen werden.
ECOCAN-BUS-Adresse Adresse des Regelgerätes, aus dem die Daten angefordert werden.
Die Adresse wird über Drehcodierschalter eingestellt.
Die Kommunikationskarte antwortet mit :
0xAB <ECOCAN-BUS-Adresse> <TYP> <OFFSET> <6 Daten-Byte>
0xAB = Kennung für Monitordaten
ECOCAN-BUS-Adresse = die abgefragte Adresse zur Bestätigung
TYP = Typ der gesendeten Monitordaten
 0x80 = Heizkreis 1 = 18 Byte
 0x81 = Heizkreis 2 = 18 Byte
 0x82 = Heizkreis 3 = 18 Byte
 0x83 = Heizkreis 4 = 18 Byte
 0x84 = Warmwasser = 12 Byte
 0x85 = Strategie wandhängend = 12 Byte
 0x87 = Fehlerprotokoll = 42 Byte
 0x88 = bodenstehender Kessel = 42 Byte
 0x89 = Konfiguration = 24 Byte
 0x8A = Heizkreis 5 = 18 Byte
 0x8B = Heizkreis 6 = 18 Byte
 0x8C = Heizkreis 7 = 18 Byte
 0x8D = Heizkreis 8 = 18 Byte
 0x8E = Heizkreis 9 = 18 Byte
 0x8F = Strategie bodenstehend = 30 Byte
 0x90 = LAP = 18 Byte
 0x92 = wandhängende Kessel 1 = 60 Byte
 0x93 = wandhängende Kessel 2 = 60 Byte
 0x94 = wandhängende Kessel 3 = 60 Byte
 0x95 = wandhängende Kessel 4 = 60 Byte
 0x96 = wandhängende Kessel 5 = 60 Byte
 
Technische Information
Änderungen aufgrund technischer Verbesserungen vorbehalten! Buderus Heiztechnik GmbH • http://www.buderus.de
 Technische Information • Monitordaten System 4000 • Ausgabe 01/2009 7
0x97 = wandhängende Kessel 6 = 60 Byte
0x98 = wandhängende Kessel 7 = 60 Byte
 0x99 = wandhängende Kessel 8 = 60 Byte
 0x9B = Wärmemenge = 36 Byte
 0x9C = Störmeldemodul = 6 Byte
 0x9D = Unterstation = 6 Byte
 0x9E = Solarfunktion = 54 Byte 
BG,
Hermann

Benutzeravatar
Black
Beiträge: 4135
Registriert: 12.09.2015, 22:31
System: Alternative CCU (auf Basis OCCU)
Wohnort: Wegberg
Hat sich bedankt: 153 Mal
Danksagung erhalten: 535 Mal
Kontaktdaten:

Re: Der Heizungskeller , RaspPI und CCU2

Beitrag von Black » 10.10.2015, 23:09

ersetz mal mein
s.write (b"\xEE\x00\x00\x10\x03\xFD")

gegen
s.write (b"\xa2\x00\x10\x03\nb1") in den Monitor Modus
das heisst du müsstest deine kiste mit dem bytestring in diesen Modus bekommen

a2 ist dein kommando, 00 = eco can adresse, 10 03 3964r endeframe, b1 checksum des frame
Wenn das Fernsehprogramm immer mehr durch nervende Werbung unterbrochen wird und der Radiomoderator nur noch Müll erzählt, ist es besser, die Zeit für sinnvolle Dinge zu nutzen - mal aufs Klo zu gehen, ein Bier zu holen oder einfach mal den roten AUS-Knopf zu drücken.
Klick - und weg

Script Time Scheduler V1.3
SDV 4.08.04A Das umfassende Entwicklungs und Diagnosetool für Homematik

technical contribution against annoying advertising

Antworten

Zurück zu „Projektvorstellungen“