Hallo, mein Ziel ist es den internen I2C-BUS der Buderus HS4201 anzuzapfen um die wesentlichen Temperaturen (Innen, Außen, Kessel, Warmwasser,...) auszulesen und die Bedienelemente (Heizung-Auto, Heizung-Tag, Heizung-Nacht und evtl auch die Vorgabetemperatur für Tag und Nacht) vorzugeben. Hierzu wird ein kleiner PIC18 die Kommunikation zur Buderus übernehmen, der allerdings nur der Mittler zu einer, auf FS20 Funktechnik bassierenden Haussteuerung, sein wird. Die FS20 Steuerung ist eine XS1 von EZControll.de. Standalone und mit hinreichender Itelligenz. Vorallem aber auch webfähig. Gibt es jemand, der schon Erfahrung damit gesammelt hat oder evtl. sogar schon Parameter / I2C Commands dekodiert hat?
Ein wenig fleißig war ich schon. Dank meines kleinen Logic-Analyser konnte ich die standard Broadcast-Meldung, die scheinbar nur die Kesseltemperatur in 2 Byte übeträgt in diesem Datensatz ermitteln. Die Werte lassen sich auch gut der angezeigten Temperatur zuordnen.
.... jedoch läßt sich nicht erkennen, wie die einzelnen Werte der Ziffern oder der gesamte Temperaturwert codiert ist. Die üblichen XOR, Nibble-Swap, OR, 2er Kompliment,... etc. funktionieren scheinbar nicht. Die Hex-Werte für den Zehner und Einserwert der Temperatur sind immer gleich. Nachkommastellen gibt es für die Kesseltemperatur scheinbar nicht. Am Ende nutzt Buderus kein ASCII für die Ziffern, sondern was eigenes. Glauben kann ich das aber nicht wirklich. Nachfolgend die Tabelle, wo die Ziffern aus der Anzeige mit den darunterstehenden Hex-Werten gepaart sind: 9 8 7 6 5 0x6F 0x7F 0x07 0x7D 0x6D 4 3 2 1 0 0x66 0x4F 0x5B 0x06 0x3F Hier noch einige Beispiele zur Verdeutlichung: Data3 Data4 Dezimal-Kesseltemperatur 0x6D 0x6D 55 0x6D 0x3F 50 Hat jemand eine Idee was da codiert wird?
Gast
#1909459
Hallo, bist du sicher das Buderus nicht nur ein EEProm (wie üblich) über I2C ansteuert ? Grüße.
Rudi schrieb: > Hallo, > > > bist du sicher das Buderus nicht nur ein EEProm (wie üblich) über I2C > ansteuert ? > > > Grüße. Hallo Rudi, nein Sicher bin ich zum jetzigen Zeitpunkt nicht. Was ich bisher sehen konnte: Es werden zwei verschiedene Geräteadressen verwendet. Wovon eines im Read und Write Mode angesprochen wird und das mit den Temperaturen nur um Write Mode. Nur ein EEprom mit der Kesseltemperatur zu beschreiben macht auch nicht wirklich sinn. Im Broadcast Datensatz kommt im Datenbyte 4 auch die Brenner An/Aus Info im Bit0 mit. Auch diese Info macht keinen Sinn in einem EEprom. Zwischenzeitlich habe ich die ersten 4 Datensätze der Bootsequenz noch gesampled und versuche dort gerade Werte zuzuordnen. Was mich wirklich kneift ist diese seltsame Codierung. Liebe Grüße Norbert
Gast
#1910566
Hallo, Norbert R. schrieb: > Nur ein EEprom mit der Kesseltemperatur zu beschreiben macht auch nicht > wirklich sinn. > > Im Broadcast Datensatz kommt im Datenbyte 4 auch die Brenner An/Aus Info > im Bit0 mit. Auch diese Info macht keinen Sinn in einem EEprom. Wenn du einen Dump der IIC Daten posten könntest wäre es etwas einfacher. Ich habe an einer Buderus Anlage relativ häufige EEProm Zugriffe gesehen, obwohl diese nicht unbedingt nötig wären. Ansonsten schau mal hier: Beitrag "Buderus Ecomatic 4000"
Dies ist der Broadcastdatensatz (Werte in Hex): Adresse r/w Data1 Data2 Data3 Data4 Data5 Data6 Bemerkung 0x38 w 0x00 0x17 0x3F 0x6D 0xE1 0xE3 05°C FK raus, FA raus, Brenner an 0x38 w 0x00 0x17 0x07 0x3F 0xE0 0xE3 70°C FK drin, FA raus, Brenner aus Data3 + Data4 enthalten die Kesser-Temperatur Data5 im Bit 0 enthält Brenner Ein/Aus
Hier die Startsequenz (Werte in Hex) Adresse r/w Data1 Data2 Data3 Data4 Data5 Data6 Bemerkung Kessel Innen Außen 0x50 w 0x10 Nach Power_on der 1. Datensatz 1. Versuch 0x50 r 0x6E 0x00 DNACK Nach Power_on der 2. Datensatz 1. Versuch 0x50 w 0x02 Nach Power_on der 3. Datensatz 1. Versuch 0x50 r 0x21 0x50 0x4A 0xD0 DNACK Nach Power_on der 4. Datensatz 1. Versuch 0x50 r 0x53 0x27 0x50 0x4A 0xD0 DNACK Nach Power_on der 4. Datensatz 2. Versuch 0x50 r 0x50 0x30 0x50 0x4A 0xD0 DNACK Nach Power_on der 4. Datensatz 3. Versuch 0x50 r 0x50 0x17 0x34 0x50 0x4A 0xD0 DNACK Nach Power_on der 4. Datensatz 4. Versuch 45°C 0x51 r 0x50 0x47 0x47 0x51 0x4A 0xD0 DNACK Nach Power_on der 4. Datensatz 5. Versuch 51°C 0x51 r 0x50 0x50 0x55 0x50 0x4A 0xD0 DNACK Nach Power_on der 4. Datensatz 6. Versuch 51°C 22°C 9°C 0x51 r 0x50 0x51 0x14 0x52 0x4A 0xD0 DNACK Nach Power_on der 4. Datensatz 7. Versuch 42°C 22°C 9°C
Wie kann man hier Tabellen vernünftig anzeigen? Etwa nur als Bild oder Anhang?
Rudi schrieb: > Hallo, > > > bist du sicher das Buderus nicht nur ein EEProm (wie üblich) über I2C > ansteuert ? > > > Grüße. Hallo Rudi, bedingt durch andere Projekte hatte ich dieses Thema bis jetzt auf Eis liegen. Nun habe ich die 4201 Steuerung mal wieder zerlegt und ein wenig Schaltpläne gemalt. Am I2C Bus hängt auch ein PCF8583T (Realtime Clock mit 240Byte RAM). Dieser ist über eine eigene Backup-Battery gepuffert und somit ist das RAM sicherlich statt eines EEPROM in Betrieb. Der I2C geht auch noch weiter auf die anderen Slots und scheint die Kommunikation mit dem KM Modul 2.0 - M 404 (eine RS232 / RS 485 Schnittstelle) sicherzustellen. Da ich dieses nicht besitze und nur Bilder der Platine habe, läßt sich jedoch der Verlauf der I2C Leitung nicht verfolgen. Leider ist das MEC (1) nicht darüber angeschlossen, sondern wird über eigene Leitungen versorgt. Was da läuft habe ich mir noch nicht angesehen.
Hallo, Für die Ecomatic 4000 mit HS4201 und KM2.0 habe ich den ESPHome Code auf GitHub eingestellt https://github.com/GernotAlthammer/buderus_ecomatic4000
Lieber Norbert, ich war auch fleissig. Ich habe das ROM des 80C652 ausgelesen und in der Funktion analysiert und habe aus die gewonnen Erkenntnissen ein ESP32 Programm erstellt welches sich exakt so verhält wie das des 80C652 original auf dem Buderus Board.
Es ist wohl so, das die Daten vom SPI Bus genommen und aufbereitet werden und via TX gesendet werden. RX ist in dem Code zwar initialisiert wird aber nicht verwendet.
Das Bedeutet original Buderus Hardware: -Eindeutige Datenrichtung -Keine Rückkopplung der Daten via RX -RX explizit als „Reserve / Service“ klassifiziert -SRAM als temporärer Arbeitsbereich
Hier ist ein grober Ablaufplan der Software im ROM
Start │ ▼ setup() │ ▼ loop() │ ├─ Timing prüfen │ ├─ SPI lesen │ ├─ Wert speichern │ └─ Aufbereiten und via RS232 senden │ └─ zurück zu loop()
FINALER ESP32-CODE:
- SPI als Datenquelle: SPI → RS232, erstmal kein Wi-Fi
- RS232, TX der Messdaten
- 2400 Baud
- internes RAM zur Daten Zwischen Speicherung
Das zur Info
Die besten Grüße, Stefan
:
Bearbeitet durch User
Hier ist das original ROM File des M404 Moduls als Hex Dump
:
Bearbeitet durch User
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.