Buderus Logamatic 2107 Revision 3 2019

[Angelo]

Nabend,

ja, leider logisch wenn man darüber nachdenkt. Hab nur gelesen, dass Du umgelötet hast und nicht weiter darüber nachgedacht welche Stecker/Buchsen dabei genutzt wurden.

Jedenfalls mit Kabel auf Notebook und HTerm kommen paar wenige Meldungen an. Leider nicht über mein langes Kabel in den Nebenraum. Denke somit, dass hier die Kabellänge von über 9 Meter zum Problem wird.

Raspi steht jetzt neben der Heizung mit einem kurzen Kabel bei dem 2+3 gedreht sind mit Stecker/Stecker.

Das Test-Python-Script für Hermann habe ich wie angegeben ergänzt. Außer einem /dev/ttyAMA0 bekomme ich aber keine Antwort.

Kannst Du nochmals Deinen letzten Stand des Test-Script einstellen?

Nach dem Quasselmode suche ich dann im Anschluss.

Viele Grüße

Angelo

[Black]

hi Angelo,

du, da kann aber bei dir im Aufbau noch irgendwas gewaltig nicht stimmen. ne RS 232 mit 9600baud geht um die 150 Meter sicher, mit 2400 baud schaffst bei abgeschirmter leitung fast nen Kilometer. Also die 11 Meter sind da peanuts, das muss auf anhieb gehen. hast denn richtig baudrate, parity und stoppbits eingestellt ? die bootup einstellung des pi ist was von 115kbaud, das geht gar nicht.

ansonsten... Pi ans eine ende der leistung, Laptop ans andere und dann mal gegenseitig via HT oder so daten senden. Wenns klappt, weisste das die HW schon mal geht.

greetz unhd viel erfolg, black

- gesendet von irgendwas mit Touchscreen von unterwegs -

[Angelo]

Nabend,

es zeigt sich erneut, man soll nicht mit zu vielen anderen Gedanken an eine Sache gehen. Zudem lohnt sich immer eine Pause.

Im Verlauf des Arbeitstag einen Teil aus dem Kopf bekommen und soeben dann auch ohne Mühe auf Anhieb den Fehler gefunden.

Das Kabel zwischen den Raspi und RS232-Adapter habe ich aus zwei enden zusammengelötet und genau da ist mir der Dreher bei RxD und TxD passiert.

Verbindung zwischen Notebook und Raspi ging dann auch direkt. Auch daran habe ich gestern nicht gedacht: Wenn serielle auf Raspi aktiviert ist, muss ich beim booten auf dem Notebook Infos bekommen. Das ging dann auch direkt.

So, soeben an meinem 9 Meter Stecker-Stecker Kabel PIN 2+3 gedreht und jetzt kommt:

80
00
80
00
80
00
80
00
80

usw.

Viele Grüße

Angelo

[Black]

Hi Angelo, die Kombi 80 0 ist eher falsch

entweder ist da nochein HW Prob oder das dingen spricht kein 3964r

Laut def sendet ein Dingen ein STX aus. als Antwort darf ein DLE, NAK oder STX kommen

aber die Codes sind komplett andere
STX ist 02h
DLE ist 10h
NAK ist 15h

und der Handshake beginnt immer mit STX (02h).. siehste andere Zahlen = HW stimmt was nicht bzw Protokoll ist kein 3964r

Gruss, Black

- gesendet von irgendwas mit Touchscreen von unterwegs -

[Black]

Aber auch dem Projekt hier gehts nun weiter...
Die gesamte Heizperiode hindurch hat mich der PI-II hier zuverlässig begleitet, ein Haufen Messwerte geliefert. und auch das ein oder andere Einsparpotential gebracht bzw aufgezeigt.

Um die CCU2 etwas zu entlasten, hab ich nun das Holen und Aufbereiten der Wetterdaten von weatherunderground in python in einem Task auf dem PI relalisiert. In Python lassen sich halt besser exception proggen, wenn mal etwas hakeln sollte. Und Primär soll die CCU die Bude automatisieren und sich nicht noch um so Kleinkram kümmern müssen.

gut, tuts nun auch.

Nun steht an, auf dem PI CCU.IO zu installieren und das ganze etwas zu visualisieren. Das reizt mich noch.
damit gehts dnan hier weiter nun

[Black]

es ging nun weiter. allerdings habe ich mich nach einigem Studium hier für IO-Broker entschieden.
jeniger läuft nun auf einem Raspi-III. dazu noch der passende 7" Touch, und ich habe eine Einheit für IO-Broker und Bedienung in Einnem. Mit dem passenden Rahmen lässt dich das auch schön Integrieren und vor allem. Ich hab ein Linux gerät. mit den Androiden kann ich net so Richtig.

In dem Abschwasch ging des dem Logamatic Script nochmal ans eingemachte. Bisher war dort ein Socket Server programmiert, über den den CCU über sein TCL Script befehle abschicken konnte. da er allerdings in einem Thread laufen musste, dieser sich aber nur recht brutal beim beenden killen liess und bei Verwendung von IO-Broker dieses Konzept nochmal auf den Prüfstand musste.
Endschied ich mich, den Socketserver gegen einen Http Server auszutauschen. Damit kann nun auch IO.broker recht einfach kommandos an das Gateway verschicken.

Mögliche Befehle an das gateway


hinzu kam auch direkt die Möglichkeit, den gesamtstatus abzufragen



Im IO-Broker bin ich grade noch dran das alles zu implementieren:
Und es ist ja grade nicht Heizperiode und eh Sommerbetrieb

Aber daskommt dabei schon mal raus im Bild: kesselübersicht

Der Boiler muss nachgeladen werden: Kessel ist gezündet und heizt über die Ladepumpe LP den Boiler.
Gleichzeitzig zu der Zustandsanzeiger der Pumpen und der Temperaturen werden auch die Laufzeiten der Pumpe und des Kessels angezeigt.


Optimiertes Boilerheizen: die Steuerung ist auf den Boiler angepasst, der kessel schaltet dann ab und heizt über die Ladepumpe LP den Boiler auf die gewünschte Solltemperatur auf.


Im Rahmen dessen wurde auc hncoh eine Hardwareoptimierung durchgeführt, den Zustand: brenner ein und Brenner Störung greife ich jetzt direkt am feuerungskontroller ab, ausgekoppelt über 2 230V Finderrelais: Grund, die Steuerung sendete schon Brenner ein an die CCU, wenn sie den Startbefehl brenner gab. Nur ein Ölbrenner beginnt dann erstmal mit dem Öl-Vorheizen. Und diese Zeit floss vorher schon in die Brennerlaufzeit ein. jetzt nicht mehr

To be continued

[Black]

Trotz des schönen Spätsommes zeigt der Blick auf den Kalender, das die nächste Heizperiode schon in der Warteschleife steht.

An dem Aufbau im Heizungskeller wurden noch 2 modifikationen nun vorgenommen:
3 mal DS18B20 Fühler an den Pi angeschlossen (Raumtemp HK keller, VL WW, und Zirktemp). Kleinen Thread geschrieben, der die Dalles Chips ausliest und die Werte in Systemvariablen auf der CCU schreibt.
Realisiert wird damit dann stuerung der Zirkulation bedarfsabhängig. wird aber auf de CCU realisiert, nicht auf dem PI.

hinzu kam auch noch ein bischen python, auf das der Pi nun Pushover nachrichten verschicken kann.
die CCU muss eigentlich nur wissen, heizung an, heizung aus, heizung fehler, welchen fehler muss sie nicht zwangsläufig wissen.
Das Auscoden der Störungsbits und erzeugen der Pushover messages hab ich auf dem PI realisiert, wieder etwas weniger, um das sich eine CCU kümmern muss.

für den, den es interessiert:

Code: Alles auswählen

import http.client, urllib
import time as t

PushOverTokenCCU = "xxToken fpr normale Message xx"
PushOverTokenWARN= "xx Token für Warn Message xx"
PushOverTokenERR = "xx Token für Error Message xx"
PushOverUser     = "Pushover User Token"

def SendPushOver (message,Token="CCU",title="CCU",priority="1"):
    # Festlegen unter welchem Token das gesendet werden soll
    if Token.upper() =="WARN":
        PushOverToken = PushOverTokenWARN
        z=  urllib.parse.urlencode({
            "token": PushOverToken,
            "user": PushOverUser,
            "message": message,
            "title": title,
            "priority": priority,  })          
    elif Token.upper() =="ERR":    
        PushOverToken = PushOverTokenERR
        z=  urllib.parse.urlencode({
            "token": PushOverToken,
            "user": PushOverUser,
            "message": message,
            "title": title,
            "priority": priority,
            "retry": "30",
            "expire": "3600",
            "sound": "siren",})          
    else:
        PushOverToken = PushOverTokenCCU
        z=  urllib.parse.urlencode({
            "token": PushOverToken,
            "user": PushOverUser,
            "message": message,
            "title": title,
            "priority": priority,  })          
    # Zusammenbauen der Message
    
  
    # Versenden
    conn = http.client.HTTPSConnection("api.pushover.net:443")    
    conn.request("POST", "/1/messages.json", z , { "Content-type": "application/x-www-form-urlencoded" })
    success= conn.getresponse()
    status= (success.status, success.read () )
    conn.close () 
    return status

Code ist eigentlich selbsterklärend. message ist klar,
token kann 3 zustände haben, "CCU" = nomale message, "WARN" und "ERR", Title ist auch klar, priority eigentlich auch, prio 2 geht hier auch, erfordert bestätigung durch user ansonsten repeats

RESÜME
gewünscht/gefordert - erfüllt
alle Schaltzustände erfassen - erfüllt (mit laufzeiten)
alle Temperaturen erfassen - erfüllt (zusätzlich VL-WW, Zirk, und raumtemp)
betrieb / fehler erfassen - erfüllt (als sammelmeldung zur CCU, fehler aufgeschlüsselt in Broker und Pushover)
einstellwerte ändern - erfüllt (mittlerweile als HTTP server auf dem PI, kann von der CCU oder Broker oder VPN , kommandos annehmen
Modus umschaltbar - erfüllt (Tag/Nacht , UrlaubsTage, Art des heizprogramms, Sommer ab)
LCD vor Ort - erfüllt
als ADDon kümmert sich der PI noch in einem Task um weather underground, die Datenaufbereitung und übertragung zur CCU
Datenaufzeichnung - erfüllt über Cuxd Logit
- verworfen - externe mySQL datenbank
- in Arbeit, teilweise umgesezt: Logging auf IO-broker
mailbenachrichtigung - gestrichen, geändert in Benachrichtung über Pushober messages

vielleicht kommt ncohmal das eine oder andere Bildchen, die weitere Arbeit ist jetzt in IO-broker mit der Visualisierung und deren WAF tauglichen Umsetzung

greetz, Black
(der python 1000 mal lieber proggt als TCL)

[Angelo]

Hallo Black,

da ich leider mit meiner Ecomatic nicht weitergekommen bin, habe ich mir jetzt spontan eine Buderus R 2107 M S0 gekauft.

Dabei sind alle Fühler usw., sodass ich erst mal "trocken" die Kommunikation testen kann, ohne gleich meine Heizung außer Betrieb zu nehmen (was im übrigen Ärger mit sich bringen würde ).

Aktuell fehlt mir nur noch die KM271 mangels Angebot.
Falls jemand mitliest und diese nicht mehr benötigt, würde ich mich über ein faires Angebot freuen.

Sobald alles da ist, versuche ich Dein Projekt nachzubauen und melde mich dann übers Forum.

Viele Grüße
Angelo

[BausatzFan]

Hallo Black,

tolles Projekt! Hat bei mir gleich den "will haben" Nerv getroffen

Ich habe einen Buderus Gas-Brennwertkessel mit logamatic mc10 (Baujahr 2009) und auch einige Raspi's hier rum liegen. Allerdings keine Ahnung von Python ...
Und ohne die Buderus KM271 geht's wohl auch nicht - die ist ziemlich teuer...

Ist Deine Lösung einfach auf meine Logamatic übertragbar?
Nutzt Du den ioBroker nur zum Loggen/Visualisieren?

Grüße,
Chris

[Black]

Da musst du in deine Anleitung schauen, welche art von Kommunikationskarte da passt.
ansonsten im Mikrokontroller forum haben sich da wohl welche was für den Buderus E-Bus gebaut.

Eigentlich ist das keine grosse schwierigkeit das signal da umzusetzen auf der 2107, musst nur aufpassen, der Bus für die Fernbienung hat andere Baudrate UND ienen Gleichspannungsoffset (dadrüber versorgt der 2107 mittels zweidraht ihre Fernbedienung)

es gibt auch einen Nachbau der KM271 (mal googlen, die KOMM tuts dabei wohl, wohl die Abgasmessung nicht. wäre aber egal in deinem anwendungsfall.

ich hatte meine mit glück gebraucht aus deer Bucht geschossen. Weil für den Preis von etwa smehr als 30 € da ne Platine für machen und selber mit pegelwandlern rumspielen muss ja nicht

das python programm hat mittlerweile über 2600 Programmzeilen und startet bei Hochlauf 5 separatete Threats, wo die einzelnen Funktionen drin laufen. Ist also alles andere als ohne.

IOBroker hab ich auf einem Raspi3, der hat wohl einen modifizierten Bootloader und kann komplett ohne SD karte nur von einer Mini festplatte booten. Also Lebendauer SD Karten ist kein Thema bei mir.

Eigentlich sollte das Anfangs mal nur zur Visu und zum loggensein...
sollte
Nur meiner Erfahrung nach läuft eine CCU2 umso besser, je mehr sie nur ihre Kernaufgaben hat und sich nciht um zeug kümmern muss wie Websites auszuwerten etc, loggings oder gar die starstellung über hichart
So wanderte damals schon weather undergrund und die push benachrichtung bei kesselalarmen auf den gateway pi

mittlerweile hab ich mich auch mit java angefreundet und schreibe nun viel logik nur noch in den javascript adaptern auf iobroker
keine RegaScript Systax mehr, wo ich mir die Finger dran brech, kein 200 variablen Bug, ich kann vernünftige Variablennamen benutzen, Unterprogramme schreiben.

Die Syntax ist da einfach übersichtilicher
mal kleines Beispiel:

Code: Alles auswählen

function set_HMCCRTDN (sRaumName,sValveChannelName,ValveChannelState) {
    var iDelay= 1000;
    // Das hier ergibt die Ventile, die in dem Raum des Thermostaten sind
    $('channel[state.id=*.VALVE_STATE](functions="Ventil")(rooms=' + sRaumName + ')' ).each (function (id, i) {
        setStateDelayed (id.replace  ("VALVE_STATE",sValveChannelName),ValveChannelState,iDelay);
        iDelay+=4000;
        log ("Gesetzt: " + id.replace  ("VALVE_STATE",sValveChannelName));
    });  
}

Dieser kleine 6 zeiler sucht alle channels, die einen State "VALVE_STATE" haben auf dem Gewerk "Ventil" und dem übergebenen raum sRaumname und setzt dort einen Channel mit dem Namen sValveChannelame auf den Wert ValveChannelState.
Nebenbei hält sich das auch noch an die Funkdisziplin in der Form, das die einzelnen Schreibbefehler an die Ventile jeweils 4000 ms verzögert werden.

mittlerwiele wird die Kesselanlage ein Teil der gesamtanlage hier, es entstehen so Funktionen, setzt meine Frau z.b. due heizungsanlage manuell auf "Tag", weil sie z.B. eher nach Hause gekommen ist, gehen bestimmte ventile in Manu betrieb auf bestimmte Temperatur. Stell ich am kessel oder über IOBroker Urlaubsmodus ein, werden auch automatisch alle WT und HK darauf eingestellt. etc etc. da bastelst sich fast jede woche eine neue funktion hinzu, weil man die im täglichen leben auf einmal sieht.

Meiner Gattin konnte ich nie die Klicki Bunti als Bedienoberfläche verkaufen, da war WAF auf der skala von 0-100 etwa bei -20, mit vis kommt sie dagegen super klar, hat ihr eigenes eingerichtetes menü, so sie ihre Sachen verstellen kann.

greetz, Black