KÖB Pyromat ECO 4: Visualisierung

Hallo Alex,

auch von mir ein herzliches Willkommen im Forum.

Wie du schon selbst festgestellt hast, sind hier nur wenige KÖB-Betreiber vertreten und die letzten Beiträge dazu sind auch schon älter. Das Thema Visualisierung für einen KÖB-Kessel hat m.W. auch noch niemand vor dir angesprochen. Es wird also tatsächlich das Beste sein, dich an den Hersteller zu wenden. Das ist in dem Falle Viessmann und den Kontakt sollte schon "der Verbauer der Anlage" herstellen. Immerhin darf er wohl weiterhin den Kundendienst machen.

Noch einen Tipp zur Suche nach KÖB-Beiträgen:
Nicht alle KÖB-Beiträge sind unter der Rubrik "KÖB Heizkessel" zu finden. Besser ist es mit der Suchfunktion (Lupe oben rechts am Bildschirm) nach dem Begriff "Pyromat" zu suchen. Wichtig ist "in allen Foren" zu suchen. Ich empfehle außerdem die "erweiterte Suche" zu verwenden, damit kann im gesamten Text und nicht nur im Betreff gesucht werden.

Auf diese Art habe ich z.B. diesen Beitrag gefunden.

Viele Grüße von Karlheinz

Man kann mich gerne anschreiben bei allen Fragen zu KÖB Produkten und deren Nachfolgern mit VIESSMANN Logo. Ich bin offizieller Servicepartner für diese Produkte und kann sicher helfen.

In dem Fall hier: Ja es ist möglich die Bus Daten bei einer Eco von KÖB auszugeben. Dies ist eine kostenpflichtige Option und muss freigeschaltet werden. Kann ich z.B. auch erledigen.
Damit hat man allerdings nur die Daten frei und noch keine Visualisierung. Da gibts auch nichts Offizielles seitens KÖB/VIESSMANN.

Aber: Wir haben eine Visualisierung entwickelt die auf PC, Laptop, Tablet, Smartphone usw. läuft. Damit lässt sich eine Eco Anlage von KÖB komplett fern steuern, überwachen usw.

Sorry, für das wiederbeleben dieses uralten Threads.

Ich glaube zwar nicht, dass sich hier noch jemand meldet, aber ein Versuch schadet ja nicht.

Verstehe ich das richtig, dass die Funktion über einen Softwarecode direkt am Pyromat ECO freigeschaltet werden kann? Sind die Daten dann direkt am CAN-Bus verfügbar, ohne Ecotronic-Controller oder sonstige Extra-Hardware.

Das Auslesen der Daten vom CAN-Bus und Visualisierung sind kein Problem, nur müsste man an die Daten erstmal rankommen und Informationen dazu sind rar.

Liebe Grüße,

Michi

Falls hier nochmal jemand drüberstolpert.

Das Auslesen vom Pyromat war bei mir möglich. Einfach das CANopen - Protokoll damit sprechen, den Ofen laut Protokoll auf operational setzen und er wird dann selbst sehr gesprächig. Er sendet dann zyklisch so ziemlich alle Daten die auch im Benutzer-Interface sichtbar sind in Form von PDO-Nachrichten.

Vermutlich könnte man auch Parameter einstellen, wenn man wollte. Freischaltungen oder dergleichen wie oben erwähnt waren bei mir nicht nötig.

Da mich jemand wegen diesem Thema angeschrieben hat, mache ich hier noch ein Update.

Mein Projekt ist mittlerweile seit Januar fertig und läuft seitdem ohne Probleme auf einem ESP32.

Anders als oben gesagt, ist CanOpen nicht nötig. Es reicht, sich einfach zu verbinden und zuzuhören.

Auch muss hier gar nichts freigeschaltet werden. Zumindest nicht bei den beiden Softwareversionen vom Kessel mit denen ich zu tun hatte.

Der Ofen spammt einen von ganz alleine mit Daten zu, wenn alles stimmt.

Hier mein Code für ESP32 (ESP-IDF). Das Programm ist ziemlich primitiv, sammelt permanent ausgewählte Daten vom CAN-Bus und schickt alle 30 Sekunden den aktuellen Stand per Lora weiter (openmqttgateway). Die Daten werden bei mir in NodeRed deserialisiert und an Home Assistant übergeben, wo dann Visualisierungen, Nachlegen-Meldung, Alarme ans Handy und was einem noch alles so einfällt eingerichtet werden kann.

https://github.com/redarflap/pyromat_to_lora/

Achtung, die Adressen können sich zwischen verschiedenen Software-Versionen der Hauptplatine vom Kessel teilweise drastisch unterscheiden.

Hallo Derb, vielen lieben Dank für deine Infos Ich liebäugle momentan auch mit so einer Lösung. Momentan hab ich einen Shelly mit Addon und ein paar Temperatursensoren an verschiedenen Stellen geklemmt, der in Home Assistant eingebunden ist. Ich würde aber gerne noch mehr Infos bekommen, daher kommt die Lösung von dir gerade recht...

Hast du schonmal an ESPHome gedacht, da müsste die Umsetzung noch einfacher sein, oder?

Und wie bist du vorgegangen, um an die Payload zu kommen? Ich hätte gern noch mehr Daten, z.B. Temperaturen der einzelnen Heizkreise etc

Viele Grüße

Hallo Ben,

ich wüsste nicht was gegen ESPHome spricht. Im Prinzip hört mein ESP nur auf dem CAN-Bus mit und parsed aus allen empfangenen Daten die Werte, die ich vorher experimentell rausgefiltert habe.

Bei mir war es nur so, dass außer LoRa kein Protokoll in Frage kam weil der Heizraum am anderen Ende eines großen Grundstücks mit allerhand Gebäuden dazwischen liegt und so war mir gleich klar, dass ich alles selber machen muss.

Um experimentell an die Datenfelder zu kommen bin ich so vorgegangen:

Jeder empfangene Datensatz besteht aus 8 Bytes.

Die ersten beiden Bytes sind die Adresse, gefolgt von 3 Zahlenwerten á 2 Bytes (Immer Integer bzw. Dezimal Format).

Temperaturen sind glaube ich immer in 10tel Grad.

Ich habe dann zum Finden der Datensätze eine kleine Logging-Funktion geschrieben, die alle empfangenen Datenpakete kontrolliert und nur etwas auf die Konsole ausgibt, wenn sich einer der drei Werte in einem gesuchten Bereich befindet.

Im Codebeispiel unten suche ich z.B. nach Werten zwischen 1400 und 1700 (140-170°C).

Wenn man das jetzt während dem Anheizen macht und den Logging-Output mit den Werten am Display vom Kessel gegencheckt, findet man recht schnell die Abgastemperatur (10tel).

Dann notiert man sich die Adresse und die Position (1/2/3) an welcher der Wert zu finden ist.

Und das macht man dann eben für alle interessanten Werte (Lüfterdrehzahl, Kesselvorlauf/Rücklauftemperatur, Klappenstellungen, Puffertemperaturen, ...).

Über das Service-Menü vom Kessel kann man auch einige Dinge manuell ansteuern, was das Finden einiger Werte erleichtert.

Ob man das so ähnlich auch mit ESPHome machen kann, weiß ich leider nicht. Habe damit 0 Erfahrung.

Wir haben keine Heizkreise die vom Kessel geregelt werden, aber die Werte wird man vermutlich genauso finden. Bei uns überwache ich die Heizkreise so wie du bisher mit Temperaturfühlern und einem separaten ESP32.

Wie schon oben gesagt, ändern sich die Positionen der Datensätze leider zwischen verschiedenen Softwareversionen der Hauptplatine. (Mussten unsere Platine und viele andere Platinen von anderen Geräten wegen einer Überspannung durch Baggerarbeiten austauschen)

Ausserdem sind manche Werte mehrfach vorhanden und nicht alle Instanzen eines Wertes werden in jedem Betriebsmodus vom Ofen gesendet. Hier hilft nur neu suchen, wenn man einen Wert erwischt hat, der z.B. nach dem Heizen plötzlich nicht mehr da ist.

    // Gesuchtes Intervall
    uint16_t from = 1400;
    uint16_t to = 1700;
    
    // Datenpaket auf drei Variablen aufteilen (LSB)
    uint16_t v1 = (rx_msg.data[3] << 8) | (rx_msg.data[2]);
    uint16_t v2 = (rx_msg.data[5] << 8) | (rx_msg.data[4]);
    uint16_t v3 = (rx_msg.data[7] << 8) | (rx_msg.data[6]);

    // Datenpaket loggen wenn Wert in Intervall gefunden
    if ((v1 > from && v1 < to) || (v2 > from && v2 < to) || (v3 > from && v3 < to))
        ESP_LOGI(EXAMPLE_TAG, "CANRX, %04x - %04u %04u %04u",
        (rx_msg.data[1] << 8) | (rx_msg.data[0]),  // Adresse vom Datensatz
        v1,
        v2,
        v3);

Ich hoffe das ist einigermaßen hilfreich.

PS: Der CAN-Bus verfügt auch über eine Versorgungsspannung. Daher wird mein ESP32 auch gleich noch vom Kessel mit Strom versorgt. Konnte zwar keine Dokumentation zur maximalen Stromstärke finden, aber für den ESP32 reicht es wohl locker. Bzgl. der Spannung bin ich mir nicht mehr ganz sicher. Glaube es waren um die 12-24V laut Dokumentation. Ich habe einfach einen Step-Down Converter mit großer Range für die Eingangsspannung genommen um die 3.3V für den ESP32 zu bekommen.

Liebe Grüße

Derb

Vielen lieben Dank

Habe noch ein paar Fragen:
An welchen CAN hast du es angeschlossen, an der Bedieneinheit oder am Ofen? Und wie hast du das mit dem Abschlusswiderstand gelöst?

Hast du den CAN vom ESP direkt angeschlossen, oder noch einen Isolator / Level-Shifter dazwischen?

Quote from Ben1337

Vielen lieben Dank

Habe noch ein paar Fragen:
An welchen CAN hast du es angeschlossen, an der Bedieneinheit oder am Ofen? Und wie hast du das mit dem Abschlusswiderstand gelöst?

Hast du den CAN vom ESP direkt angeschlossen, oder noch einen Isolator / Level-Shifter dazwischen?

Angeschlossen hab ich hinten am Ofen am DB9 Stecker.

Der ESP32 unterstützt zwar das CAN-Bus Protokoll (heisst dort aus lizenzrechtlichen Gründen TWAI), aber man braucht trotzdem immer einen separaten Transceiver. Ich habe dafür glaube ich ein fertiges Modul mit MCP2515 im Einsatz. Auf dem Modul müsste auch der Abschlusswiderstand drauf sein, wenn ich mich richtig erinnere.

Ich schaue mir morgen nochmal die Schaltung an und mache ein paar Fotos.

Sorry für die späte Rückmeldung.

Hier die versprochenen Fotos.

Ich hatte mich offenbar doch für einen VP230 CAN-Transceiver entschieden (weiß nicht mehr warum, der MCP2515 müsste auch mit 3.3V funktionieren) und ihn auf ein einsteckbares Test-Board gelötet. Der Widerstand auf der Rückseite der Platine dürfte der Abschlusswiderstand sein, oder der befindet sich im Stecker. Habe damals leider nix dokumentiert. Einfach das Datenblatt konsultieren oder ein fertiges Modul kaufen.

Das fertige ESP32 Lilygo Board hatte ich damals gewählt, weil es LoRa schon an Bord hatte.

Der Buck-Converter für die Versorgungsspannung generiert 3.3V aus 4.5 - 28V und basiert auf dem MP1584EN Chip.

Würde ich das ganze nochmal machen, würde ich vermutlich eine Platine designen, bei JLCPCB fertigen lassen und selbst bestücken (ESP32 Wroom Modul). Braucht zwar etwas Erfahrung und Zeit, wäre aber ein tolles Projekt mit einem schönen kompakten Ergebnis.

Der Vorteil bei der steckbaren Lösung ist allerdings, dass man eine kaputte Komponente relativ schnell ersetzen könnte.

LG

Derb

Hallo zusammen.

Derb und ich hatten letztes Jahr schon über PM eine Unterhaltung bzgl. Pyromat Datenempfang.

Ich möchte euch meine Fortschritte seit dem präsentieren:

Ich hatte es letztes Jahr auch geschafft mittels ESP32 Entwicklungsboard und angeschlossenem MCP2515 Board Daten direkt am CAN-Bus vom Pyromaten zu empfangen. Leider konnte ich aber in dem Byte-Wirr-Warr nicht wirklich Muster erkennen.

Habe bis vor einer Woche daher leider auch keine großen Fortschritte machen können.

Aber da kam ich auf die Idee, den Bus-Datenlog zusammen mit Derbs-Erkenntnissen aus seinem Programm, Gemini-Pro zur Verfügung zu stellen und die KI das analysieren zu lassen.

Gemini konnte innerhalb weniger Sekunden tatsächlich Muster bzw. Werte erkennen! Leider natürlich ohne konkrete Zuordnung (also ob Puffertemperatur usw.) Ich habe dann den Pyromaten angefeuert und mit Hilfe der sich veränderten Ist-Daten (z.B. Abgastemperatur) und im gegenseitigen Gespräch mit Gemini und stetiger Übergabe aktueller Datenlogs konnten wir alle für mich relevanten Werte ermitteln und zuordnen! Um die für Gemini nützlichen Bus-Daten-Logs zu bekommen, habe ich einen kleinen simplen "CanBus-Detektiv" in Arduino entwickelt, der die Daten auf der Konsole ausgibt. Diese kann man dann einfach per Copy Paste Gemini zum analysieren geben.

Nächster Schritt war dann die Entwicklung eines Yaml für EspHome. Das habe ich dann nach ein paar Versuchen auch hinbekommen.

Nun ist der ESP32 schön hinter dem Display vom Pyromaten eingebaut und funkt fleißig über WLAN die Daten zu meinem MQTT-Adapter auf meinem iobroker-Server! Jetzt kann ich mich endlich an eine Visualisierung und Automation machen - Klasse!

Ich lade die "Detektiv-Datei" und ESP-Home yaml mal hier hoch. Ist ja für den ein oder anderen interessant. Die case-Werte in der switch-Funktion sind die für meinen Pyromaten zutreffenden Werte, die wie Derb schon schrieb, bei jeder Pyromat-Software unterschiedlich sein kann. Aber wie gesagt, kann man gut mit Gemini oder ChatGPT zusammen "erforschen".

Falls noch Fragen sind einach melden!

Hier auch noch die Verkabelung des MCP2515-Moduls mit dem ESP32

ESP32 5V → Modul VCC

ESP32 GND → Modul GND

ESP32 GPIO 23 (MOSI) → Modul SI (Slave In)

ESP32 GPIO 19 (MISO) → Modul SO (Slave Out)

ESP32 GPIO 18 (SCK)** → Modul **SCK` (Serial Clock)

ESP32 GPIO 5 (CS)** → Modul **CS` (Chip Select)

ESP32 GPIO 4 → Modul INT (Interrupt)

Modul H → CAN-High-Draht Pyromat

Modul L → CAN-Low-Draht Pyromat

Endwiderstand habe ich nicht gebraucht

Hallo Landvogt,

freut mich, dass es auch bei dir mit dem Auslesen geklappt hat.

Gute Idee, die KI für die Aufgabe zu bemühen. Wäre mir das am Anfang eingefallen wäre ich wahrscheinlich auch schneller zu einem brauchbaren Ergebnis gekommen.

Falls du den Kessel grafisch visualisieren möchtest, ich habe eine 3D-Zeichnung davon gemacht. Die überlagere ich bei mir in Home Assistant mit Labels für die einzelnen Sensoren. Siehe Anhang.

Übrigens ist mir aufgefallen, dass sich die Adressen in deiner .yaml Datei großteils mit meinen ermittelten Adressen decken. Falls dir noch was fehlt könntest du vielleicht bei meinen Werten noch was brauchbares finden.

Siehe Funktion parseData:

Die Variablen sind bei mir allerdings alle Englisch und teilweise etwas ungeschickt übersetzt.

Quote from der_landvogt

Hallo zusammen.

Derb und ich hatten letztes Jahr schon über PM eine Unterhaltung bzgl. Pyromat Datenempfang.

Ich möchte euch meine Fortschritte seit dem präsentieren:

Ich hatte es letztes Jahr auch geschafft mittels ESP32 Entwicklungsboard und angeschlossenem MCP2515 Board Daten direkt am CAN-Bus vom Pyromaten zu empfangen. Leider konnte ich aber in dem Byte-Wirr-Warr nicht wirklich Muster erkennen.

Habe bis vor einer Woche daher leider auch keine großen Fortschritte machen können.

Aber da kam ich auf die Idee, den Bus-Datenlog zusammen mit Derbs-Erkenntnissen aus seinem Programm, Gemini-Pro zur Verfügung zu stellen und die KI das analysieren zu lassen.

Gemini konnte innerhalb weniger Sekunden tatsächlich Muster bzw. Werte erkennen! Leider natürlich ohne konkrete Zuordnung (also ob Puffertemperatur usw.) Ich habe dann den Pyromaten angefeuert und mit Hilfe der sich veränderten Ist-Daten (z.B. Abgastemperatur) und im gegenseitigen Gespräch mit Gemini und stetiger Übergabe aktueller Datenlogs konnten wir alle für mich relevanten Werte ermitteln und zuordnen! Um die für Gemini nützlichen Bus-Daten-Logs zu bekommen, habe ich einen kleinen simplen "CanBus-Detektiv" in Arduino entwickelt, der die Daten auf der Konsole ausgibt. Diese kann man dann einfach per Copy Paste Gemini zum analysieren geben.

Nächster Schritt war dann die Entwicklung eines Yaml für EspHome. Das habe ich dann nach ein paar Versuchen auch hinbekommen.

Nun ist der ESP32 schön hinter dem Display vom Pyromaten eingebaut und funkt fleißig über WLAN die Daten zu meinem MQTT-Adapter auf meinem iobroker-Server! Jetzt kann ich mich endlich an eine Visualisierung und Automation machen - Klasse!

Ich lade die "Detektiv-Datei" und ESP-Home yaml mal hier hoch. Ist ja für den ein oder anderen interessant. Die case-Werte in der switch-Funktion sind die für meinen Pyromaten zutreffenden Werte, die wie Derb schon schrieb, bei jeder Pyromat-Software unterschiedlich sein kann. Aber wie gesagt, kann man gut mit Gemini oder ChatGPT zusammen "erforschen".

Falls noch Fragen sind einach melden!

Hier auch noch die Verkabelung des MCP2515-Moduls mit dem ESP32

ESP32 5V → Modul VCC

ESP32 GND → Modul GND

ESP32 GPIO 23 (MOSI) → Modul SI (Slave In)

ESP32 GPIO 19 (MISO) → Modul SO (Slave Out)

ESP32 GPIO 18 (SCK)** → Modul **SCK` (Serial Clock)

ESP32 GPIO 5 (CS)** → Modul **CS` (Chip Select)

ESP32 GPIO 4 → Modul INT (Interrupt)

Modul H → CAN-High-Draht Pyromat

Modul L → CAN-Low-Draht Pyromat

Endwiderstand habe ich nicht gebraucht

Display More

Sehr schön Ich werde es mir über den Weihnachtsurlaub vornehmen.

Wenn ich das richtig verstanden habe, nutzt du den CAN-Anschluss in der Bedieneinheit und nicht am Ofen selber, richtig?

Ja, tatsächlich nutze ich den Stecker auf der Haupt-Platine hinter dem Display. Von diesem habe ich die Verbindungskabel zum DSUB-9-Stecker abgeschraubt (Der Stecker an der Rückseite vom Holzvergaser) und habe statt dessen den MCP/ESP32 angeschlossen (A/B/24V/GND) - die 24V gehen an eine DC-DC Step-Down Platine, die aus den 24V 5v für die Versorgung des ESP32 macht.

Nur zur Ergänzung:

Ich habe das ESPHome-Projekt mit .yaml Datei auch auf Github und werde dort auch immer die neueste Version bereit stellen:

Quote from Derb123

Sorry für die späte Rückmeldung.

Hier die versprochenen Fotos.

Ich hatte mich offenbar doch für einen VP230 CAN-Transceiver entschieden (weiß nicht mehr warum, der MCP2515 müsste auch mit 3.3V funktionieren) und ihn auf ein einsteckbares Test-Board gelötet. Der Widerstand auf der Rückseite der Platine dürfte der Abschlusswiderstand sein, oder der befindet sich im Stecker. Habe damals leider nix dokumentiert. Einfach das Datenblatt konsultieren oder ein fertiges Modul kaufen.

Das fertige ESP32 Lilygo Board hatte ich damals gewählt, weil es LoRa schon an Bord hatte.

Der Buck-Converter für die Versorgungsspannung generiert 3.3V aus 4.5 - 28V und basiert auf dem MP1584EN Chip.

Würde ich das ganze nochmal machen, würde ich vermutlich eine Platine designen, bei JLCPCB fertigen lassen und selbst bestücken (ESP32 Wroom Modul). Braucht zwar etwas Erfahrung und Zeit, wäre aber ein tolles Projekt mit einem schönen kompakten Ergebnis.

Der Vorteil bei der steckbaren Lösung ist allerdings, dass man eine kaputte Komponente relativ schnell ersetzen könnte.

LG

Derb

Display More

So ESP32, CAN-Bus-Transceiver und Step-Down sind bestellt

Hast du die Pinbelegung des DSUB parat? Ich werde auch direkt an die CAN-Buchse am Ofen gehen wie du

Kannst du ja durchpiepsen. Die Belegung an der Platine ist im Schaltplan der Serviceanleitung ersichtlich....

Ja das ginge auch. Jetzt hab ich grad wegen was Anderem noch nach weiteren Anleitungen gesucht, da habe ich Folgendes gefunden (Hoffe das stimmt, und soll hier für Nachahmer festgehalten werden):

Pin 7 -> CAN H

Pin 2 -> CAN L

Pin 3 -> CAN GND

Pin 8 -> 24V+

Pin 5 -> 24V-

Also habe bei mir das Ganze jetzt auch umgesetzt und elektrisch lief es sofort, CAN-Nachrichten kamen auch direkt rein.

Allerdings unterscheidet sich das Protokoll komplett von Eurem.

Ich habe mir die CAN-Frames der Pyromat/Heizung im Little Endian (LE)-Wortformat (je Wort 16 bit) gemappt: w0=Byte0..1, w1=Byte2..3, w2=Byte4..5, w3=Byte6..7.

ID 0x381 (8 Byte): w0 = Ofen-Vorlauf [°C] = u16/100, w1 = Ofen-Rücklauf [°C] = u16/100, w2 = Abgastemperatur [°C] = u16/10, w3 = Restsauerstoff [%] = u16/100.

ID 0x382 (≥6 Byte): w0 = Heizung-Vorlauf Altbau [°C] = u16/100, w1 = Vorlauf Altenteil 1 [°C] = u16/100, w2 = Vorlauf Altenteil 2 [°C] = u16/100.

ID 0x481 (≥6 Byte): w0 = Speicher oben [°C] = u16/100, w1 = Speicher mitte [°C] = u16/100, w2 = Speicher unten [°C] = u16/100.

Decode-Formel überall: u16 = byte[i] + (byte[i+1] << und dann je Signal durch 100 bzw. 10 skalieren.

Es kommen noch mehr Nachrichten, daraus haben ChatGPT und ich bisher aber nichts brauchbares herausholen können.

Alles in Allem bin ich aber zufrieden mit der Lösung, läuft sehr stabil. Ich habe im Vergleich zu meiner Lösung mit einzelnen Temperaturfühlern (über Shelly AddOn) nun einige Werte mehr und weniger Kabelsalat um den Ofen herum. Hätte nur gerne noch die Klappenstellung der Primär- und Sekundärluftklappe gehabt, ansonsten fehlt mir aber nichts.

Vielen vielen Dank, dass ihr soviele Infos geteilt habt, ansonsten hätte ich das Projekt nicht umsetzen können!