Pfusch 
Hier die Korrektur:
| Dienst | Länge | Kennung | Antwort | |
|---|---|---|---|---|
| 5000 | 03 | 23029B | 02000b | |
| 5000a | 03 | 93129B | 03000b04 | |
| 5000a | 03 | 1F229B | 04000b0433 | |
| 5000a | 03 | AF329B | 05000b0433e4 |
Ich probiere grad mit deinen Daten den CRC herauszufinden: http://reveng.sourceforge.net/readme.htm
Aber wieso sagst du „vorletztes Byte“ (Länge) und „drittletztes Byte“ (CRC)? Die stehen doch ganz vorne?
Die SYC-Dateien hab ich auch mal auseinandergenommen, als Trenner fungiert da „0x05“, dann kommt die Länge des Textes und noch drei weitere Bytes… Aber was die heißen?
Hier mal ein Auszug:
7A
FFFFFFC7: 00 FFFFFFE0 00 20 00 79
07: AB_0000 2B 00 79
0C: AIN_ERR_MASK FFFFFFBC 00 79
0F: AIN_FS_ERR_MASK FFFFFFBF 00 79
06: ANAIN4 66 00 79
0A: Aufruf_von
00: 79
0A: Aufruf_von
00: 79
0C: BE1_50HZ_CNT 4C 00 79
0C: BE2_50HZ_CNT 4D 00 79
0C: BE3_50HZ_CNT 4E 00 79
0C: BE4_50HZ_CNT 4F 00 79
0C: BE5_50HZ_CNT 50 00 79
0F: Bezeichnung_INr 06 00 79
0F: Bezeichnung_PNr 06 00 79
0B: CALIB_STATE 7A 00 79
0E: CNTNETZPERIODE 7E 00 79
0B: CONSIS_MARK 24 00 79
0B: DL_COMF_HYS FFFFFF9A 00 79
0B: DL_DT_VORST FFFFFFA9 00 79
44: L_KPû y
07: DL_KTND FFFFFF97 00 79
09: DL_NORMAL FFFFFF98 00 79
07: DTMAXWT FFFFFFAA 00 79
08: DYGPVREL FFFFFFCB 00 79
04: Divi 04 00 79
08: Drehzahl 07 00 79
09: EBUS_BITS 26 00 79
07: EB_0000 27 00 79
07: EB_0001 28 00 79
0C: EE_CONST_CRC 41 00 79
0B: EP15RTHZEIT FFFFFFA0 00 79
0C: EP17HZSONDER FFFFFFA1 00 79
0C: EP33ABGASSTB FFFFFFA3 00 79
0A: EPGPVSTART FFFFFFA8 00 79
0C: EPION_XW_TOL 3E 00 79
09: EPYGPVLIN 3C 00 79
0A: EPYGPVOFFS 3B 00 79
0A: EPYGPVQUAD 3D 00 79
0A: EPYGPV_TOL 3F 00 79
08: ERR_MERK 23 00 79
0C: ERR_MERK_ALT FFFFFFC0 00 79
06: F_CODE 65 00 79
0A: F_CODE_ALT FFFFFFC1 00 79
04: HK_S FFFFFF9B 00 79
08: HZZUSTBM 72 00 79
06: HZ_HYS FFFFFF81 00 79
48: Z_KPâ y
07: HZ_KTND FFFFFF84 00 79
0A: ICL100MSEC 54 00 79
07: ICL1HRS 56 00 79
0B: ICL1HRS_ALT FFFFFFD0 00 79
08: ICL20SEC 55 00 79
0C: INETZPERIODE 7D 00 79
06: IONIST 60 00 79
0C: ION_ERR_MASK 7B 00 79
0C: ION_ERR_TIME FFFFFFCD 00 79
06: ION_KP FFFFFF91 00 79
07: ION_KTN FFFFFF92 00 79
0E: ION_REG_ANPASS FFFFFFA7 00 79
08: ION_SOLL FFFFFFB5 00 79
0C: ION_SOLL_AKT FFFFFFCC 00 79
06: ION_XW FFFFFFD4 00 79
07: IO_KORR FFFFFF8E 00 79
09: IRAEPKANF FFFFFF80 00 79
09: IRAEPMANF FFFFFFAE 00 79
08: KESS_OPT FFFFFFAC 00 79
0B: KES_DAT_CRC FFFFFFAD 00 79
07: KEY_ACT 57 00 79
07: KEY_CNT 59 00 79
08: KEY_PREV 58 00 79
0B: MAINPARACRC FFFFFFB4 00 79
0D: MAXBWLADEZEIT FFFFFF95 00 79
09: MAXTVSOLL FFFFFF80 00 79
07: MB_0000 2C 00 79
07: MB_0001 2D 00 79
07: MB_0002 2E 00 79
07: MB_0003 2F 00 79
08: MB_2_ALT 4B 00 79
07: MENU_NR 5A 00 79
09: MINTVSOLL FFFFFFA5 00 79
0B: MXGRADTVIST FFFFFFAB 00 79
07: MXSTB_A 3A 00 79
07: MXSTB_K 38 00 79
07: MXSTW_K 39 00 79
07: Maximum
00: 79
07: Maximum 07 00 79
09: Menupunkt 63 00 79
07: Minimum 07 00 79
07: Minimum
00: 79
4D: ulti y
4E: GISTq y
07: NGIST_2 FFFFFFD2 00 79
09: NGIST_CNT 50 00 79
06: NGSOLL 70 00 79
4E: GXW1║ y
09: NG_BR_MIN 40 00 79
09: NG_GR_MAX 37 00 79
09: NG_GR_MIN 36 00 79
0A: NG_HZ_FREI FFFFFF86 00 79
09: NG_HZ_MAX FFFFFF87 00 79
0D: NG_KESSEL_MAX FFFFFF9D 00 79
0D: NG_KESSEL_MIN FFFFFF85 00 79
4E: G_KPÅ y
06: NG_KTN FFFFFF90 00 79
0A: NG_MAX_LOW 33 00 79
06: NG_NSP 35 00 79
0D: NG_REG_ANPASS FFFFFFA6 00 79
0C: NG_START_PWM FFFFFF94 00 79
09: NG_TRUDEL FFFFFFA2 00 79
06: NG_VSP 34 00 79
09: NG_WW_MAX FFFFFF8D 00 79
08: NG_ZUEND FFFFFFA4 00 79
08: OffValue 07 00 79
06: PNL_HZ FFFFFF88 00 79
09: PNL_HZCNT FFFFFFB6 00 79
09: PNL_WWCNT FFFFFFB8 00 79
09: PREVIONTH 7C 00 79
08: PUHZOFFS FFFFFF89 00 79
07: PUHZPWM FFFFFFBB 00 79
09: PUHZSTEIG FFFFFF8A 00 79
06: PWMGPV 61 00 79
0D: Parameterwert 64 00 79
0A: Pt_History 07 00 79
07: RES_CNT 52 00 79
0B: RES_CNT_ALT FFFFFFD1 00 79
0B: RES_CNT_INV 53 00 79
0C: RES_CYCL_CNT 51 00 79
07: ROM_DPH FFFFFFC2 00 79
07: ROM_DPL FFFFFFC3 00 79
52: OM_H─ y
52: OM_L┼ y
0A: S5_DAT_CRC 4A 00 79
0B: S5_ERR_CODE 5B 00 79
0C: SMON_TIMEOUT 67 00 79
0A: SOMMERTEMP FFFFFFB0 00 79
53: TACK╒ y
06: TABGAD FFFFFFBE 00 79
06: TABGAS 5F 00 79
07: TAUSSAD FFFFFFBD 00 79
07: TAUSSEN 5E 00 79
0C: TAUSSEN_KORR FFFFFF9C 00 79
09: TBRMINOFF FFFFFF82 00 79
54: CNSP2 y
54: CSZA1 y
54: CVSP0 y
0B: TFRS_ANLAGE FFFFFF9F 00 79
0B: TRAUMABSENK FFFFFFB3 00 79
08: TRAUMTAG FFFFFFB2 00 79
08: TVABSENK FFFFFFAF 00 79
54: VISTh y
07: TVISTAD 5C 00 79
06: TVSOLL 6E 00 79
0A: TVSOLL_EPM FFFFFFAE 00 79
06: TWWIST 6A 00 79
08: TWWISTAD 5D 00 79
07: TWWPLUS FFFFFF8C 00 79
0B: TWWSOLL_EPM FFFFFFB1 00 79
0A: TWWSOLL_HS 6F 00 79
06: T_0108 29 00 79
0B: T_CALT_0108 2A 00 79
0A: T_CNT_0001 42 00 79
0A: T_CNT_0002 43 00 79
0A: T_CNT_0003 44 00 79
0A: T_CNT_0004 45 00 79
0A: T_CNT_0005 46 00 79
0A: T_CNT_0006 47 00 79
0A: T_CNT_0007 48 00 79
0A: T_CNT_0008 49 00 79
08: V24_CCMD 69 00 79
08: V24_IADR 6B 00 79
0A: V24_KM_ADR FFFFFF93 00 79
08: V24_ODAT 6C 00 79
0C: V24_RXCNT1MS 6D 00 79
0C: V24_SCOM_ADR FFFFFFC6 00 79
09: V24_TXCNT 73 00 79
56: alue♠ y
08: WWZUSTBM 74 00 79
09: WW_ABSENK FFFFFF99 00 79
0B: WW_FLOW_CNT 79 00 79
06: WW_HYS FFFFFF8B 00 79
07: YGPVOPT FFFFFFC9 00 79
09: YGPVSTART FFFFFF9E 00 79
07: YIONREG FFFFFFC7 00 79
04: YPWM 77 00 79
06: YTVREG 75 00 79
0A: aMenupunkt
…„vorletztes“, „drittletztes“… diese stümperhaften Angaben sollte man nicht überbewerten 
Wichtig ist, dass wir vorankommen! 
und das machen wir! 
Irgendwie sollte man doch die „Adressen“ der Telegramme auch in den syc-Dateien finden?
Bin mal gespannt, was Du noch herausbekommst! 
Die nächsten Tage komm ich selbst allerdings nicht dazu, weiter zu machen… :eek:
Statistik:
PB: 50 SB: 00 MS: 03 58 B2 9C
88 178 156
B -> Länge Anwort
2 9C 668 -> Adresse im Speicher? immer + 12
Die Länge und Adresse macht echt Sinn, super!
Steht auch in der Tabelle für die WTC32 drin, ist denn hier die „2“ hinter „B“ zur Adresse gehörig oder ist das das Kommando?
Ich komm leider nicht drauf wie sich das erste Byte errechnen läßt…
Hallo geronet
Ich bin mir ziemlich sicher, dass in Deinem Beispiel „B“ die Länge der zu lesenden Daten (0 -> 1 Byte, B -> 12 Byte) und „29C“ die Adresse ist.
Für die Telegramme, die im Master-Teil 5 Bytes haben (z.B. „03029F8263“, das erste Telegramm in meiner Definition der Fehlerhistorie), habe ich ebenfalls eine Theorie: das könnte eine Doppel-Abfrage sein.
03 - Check-Byte
0 - Länge erste Abfrage (0 -> 1 Byte)
29F - Adresse erste Abfrage
8 - Länge zweite Abfrage (8 -> 9 Byte)
263 - Adresse zweite Abfrage
Das ergibt eine Länge der nutzbaren Antwort (abzüglich des ersten Bytes, das immer null zu sein scheint) von 10 Byte - und das hat sie auch! 
Ich denke, dass sich die Reihe für Telegramme mit 7 und 9 Byte im Master-Teil fortsetzen lässt…
Über „reveng“ bin ich bei meiner Suche nach dem Check-Algorithmus auch gefallen… ebenfalls erfolglos!
Das Tool bzw. die Thematik ist für Ahnungslose wie mich zu kompliziert…
Update: Ich habe einen Versuch mit der Definition des ersten Telegramms gestartet.
Ursprünglich sieht die Anfrage und Antwort wie folgt aus:
pi@raspberrypi:~ $ ebusctl hex 0850000503029F8263
0b00041606520021230af934
Mit der Annahme, dass hier zwei Adressbereiche ausgelesen werden, habe ich daraus folgende Anfrage gemacht, die nur den ersten Bereich ausliest (das Check-Byte habe ich durch Probieren ermittelt):
pi@raspberrypi:~ $ ebusctl hex 0850000327029F
020004
Damit ist wohl ein weiteres Geheimnis gelüftet… :eek:
Dann ist Befehl 50 00 also Speicher lesen mit Prüfsumme bzw. CRC und Länge/Adresse.
Befehl 50 01 Speicher schreiben und als Antwort kommt 50 02 mit Länge=1 und einer 0 zurück.
Werd später mal im Mikrocontroller-Forum was über die Prüfsummer schreiben, die Jungs sind da spitze.
Berechnung des Check-Bytes
Ich wage zu behaupten, dass das Check-Byte ein CRC8 mit Polynom 0x5C ist.
Als Beispiel muss folgender Aufruf herhalten:
pi@raspberrypi:~ $ ebusctl hex 0850000327029F
Es gilt, den roten Teil, das Check-Byte, aus dem grünen Teil zu berechnen.
Hier eine sog. Lookup Table für das Polynom 0x5C
Lookup Table:
0x00 0x5C 0xB8 0xE4 0x2C 0x70 0x94 0xC8 0x58 0x04 0xE0 0xBC 0x74 0x28 0xCC 0x90
0xB0 0xEC 0x08 0x54 0x9C 0xC0 0x24 0x78 0xE8 0xB4 0x50 0x0C 0xC4 0x98 0x7C 0x20
0x3C 0x60 0x84 0xD8 0x10 0x4C 0xA8 0xF4 0x64 0x38 0xDC 0x80 0x48 0x14 0xF0 0xAC
0x8C 0xD0 0x34 0x68 0xA0 0xFC 0x18 0x44 0xD4 0x88 0x6C 0x30 0xF8 0xA4 0x40 0x1C
0x78 0x24 0xC0 0x9C 0x54 0x08 0xEC 0xB0 0x20 0x7C 0x98 0xC4 0x0C 0x50 0xB4 0xE8
0xC8 0x94 0x70 0x2C 0xE4 0xB8 0x5C 0x00 0x90 0xCC 0x28 0x74 0xBC 0xE0 0x04 0x58
0x44 0x18 0xFC 0xA0 0x68 0x34 0xD0 0x8C 0x1C 0x40 0xA4 0xF8 0x30 0x6C 0x88 0xD4
0xF4 0xA8 0x4C 0x10 0xD8 0x84 0x60 0x3C 0xAC 0xF0 0x14 0x48 0x80 0xDC 0x38 0x64
0xF0 0xAC 0x48 0x14 0xDC 0x80 0x64 0x38 0xA8 0xF4 0x10 0x4C 0x84 0xD8 0x3C 0x60
0x40 0x1C 0xF8 0xA4 0x6C 0x30 0xD4 0x88 0x18 0x44 0xA0 0xFC 0x34 0x68 0x8C 0xD0
0xCC 0x90 0x74 0x28 0xE0 0xBC 0x58 0x04 0x94 0xC8 0x2C 0x70 0xB8 0xE4 0x00 0x5C
0x7C 0x20 0xC4 0x98 0x50 0x0C 0xE8 0xB4 0x24 0x78 0x9C 0xC0 0x08 0x54 0xB0 0xEC
0x88 0xD4 0x30 0x6C 0xA4 0xF8 0x1C 0x40 0xD0 0x8C 0x68 0x34 0xFC 0xA0 0x44 0x18
0x38 0x64 0x80 0xDC 0x14 0x48 0xAC 0xF0 0x60 0x3C 0xD8 0x84 0x4C 0x10 0xF4 0xA8
0xB4 0xE8 0x0C 0x50 0x98 0xC4 0x20 0x7C 0xEC 0xB0 0x54 0x08 0xC0 0x9C 0x78 0x24
0x04 0x58 0xBC 0xE0 0x28 0x74 0x90 0xCC 0x5C 0x00 0xE4 0xB8 0x70 0x2C 0xC8 0x94
Hier etwas Pseudo-Code…
// Funktionsdefinition: Lookup mit aktuellem CRC-Wert und XOR mit neuem Wert ergibt CRC-Wert
void AddCRC(Byte value)
{
m_crc = CRC_LOOKUP_TABLE[m_crc]^value;
}
// Berechnung mit 0x029F
m_crc = 0 // Initialisierung
// Aufruf mit erstem Byte
AddCRC(0x02)
// -> CRC_LOOKUP_TABLE[0x00] -> 0x00
// -> 0x00 ^ 0x02 -> m_crc = 0x02
// Aufruf mit zweitem Byte
AddCRC(0x9F)
// -> CRC_LOOKUP_TABLE[0x02] -> 0xB8
// -> 0xB8 ^ 0x9F -> m_crc = 0x27
Und das Ergebnis passt!
Hm, passt bei mir nur bei einem einzigen Telegramm mit 3 Bytes Nutzdaten…
Ui ne, das passt sogar! Hab grade deinen Pseudocode als C-Programm probiert, da stimmts! Super
Mit dem Online CRC Berechner funktionierts nicht wirklich… warum?
Sunshine’s Homepage - Online CRC Calculator Javascript
…online klappts nicht, weil Du das letzte Byte in „Final Xor Value“ eintragen musst statt in „CRC Input Data“…
…aber frag nicht warum!
Dann kann ich nun die Tabelle umgestalten bzw. eine neue scheiben, welcher Wert an welcher Adresse steht? bzw. gleich eine Liste. Ist echt super! Hab bisher angenommen ich muss die Telegramme 1:1 übernehmen um an die Daten zu kommen und entsprechend C-Code geschrieben… Nu is das ja viel einfacher 
So, ich hab die Tabelle mal ein bisschen umgearbeitet und gesehen, daß die Annahme mit der Reihenfolge des Requests:
CRC/Länge/Adresse/Länge/Adresse/…
bei dem WTC32 bis auf die Fehlerliste genau passt. Wenn du dir die Fehlerliste mal anschaust und bei dem WTC-OB-45 die Prozesswerte, sieht man daß dort vor den Längen/Adressen immer was mit 06/01 oder 06/E1, 06/E2, 06/E3 oder 06/FD steht (anders passt sonst die Antwortlänge nicht). Ist das vielleicht die „Vorauswahl“ für den Speicherbereich?
Für den CRC hab ich eine C-Funktion geschrieben, die mit dem richtigen Polynom den CRC für den Ebus und für die Weishaupt-Telegramme ausrechnen kann. Brauchst du die?
Ebus-Telegramme.xls (185 KB)
Hallo geronet :o
Ja, der C-Code würde mich interessieren!
Zur „Vorauswahl“ (0601 usw.) kann ich nix sagen… Kommt die selbe Antwort, wenn man die zwei Bytes der „Vorauswahl“ einfach weglässt?
Ohne die „Vorwahl“ kommt zwar die richtige Länge, aber andere Daten.
Ich erweitere zur Zeit die Tabelle mit den Adressen, daß man mal eine Übersicht hat welche Werte wo stehen. Die müssten dann ja auch irgendwie in den SYC Dateien zu finden sein? Mal schauen.
Mit den komplizierten Tabellenfunktionen zeigt es jetzt auch die Sende-Telegramme direkt aufgelöst an.
Hier die CRC-Funktion:
#define EBUS_CRC_POLY 0x9B
#define EBUS_CRC_WEISHAUPT_POLY 0x5C
/**
* @name ebus_calc_crc
* Berechnet den 8-Bit CRC mit dem angegebenem Polynom
* @param poly CRC-Polynom (siehe #define)
* @param crc CRC Initialisierungswert (0 oder vorherig berechneter Wert)
* @param byte Datenbyte
* @return Berechneter CRC
**/
uint8_t ebus_calc_crc(uint8_t poly, uint8_t crc, uint8_t byte)
{
uint8_t i, polynom;
for (i = 0; i < 8; i++)
{
if (crc & 0x80)
polynom = (uint8_t) poly;
else
polynom = (uint8_t) 0;
crc = (uint8_t) ((crc & ~0x80) << 1);
if (byte & 0x80)
crc = (uint8_t) (crc | 1);
crc = (uint8_t) (crc ^ polynom);
byte = (uint8_t) (byte << 1);
}
return crc;
}
uint8_t = unsigned char
Beim ersten Byte Aufruf mit 0 initialisieren (Startwert)
uint8_t poly = EBUS_CRC_WEISHAUPT_POLY;
uint8_t crc = ebus_calc_crc(poly, 0, byte0);
zweiter Aufruf:
crc = ebus_calc_crc(poly, crc, byte1)
usw.
Wie hast du das Polynom herausgefunden? Hab echt viel probiert mit den CRC-Rechnern, bin aber nicht draufgekommen
Wie man hier sieht, liest er in einem Telegramm die gleiche Speicheradresse zweimal aus, nur mit anderem Vorwähler.
Der erste Byte ist die Anzahl der Fehler im Speicher, der zweite Teil dann der Fehlerlistenanfang.
Na, dann sieht die Geschichte doch inzwischen recht gut aus!
Wie ich das Polynom herausgefunden habe? :rolleyes:
Jetzt wo ich weiß wie, eigentlich ganz einfach: ich habe mir die CRC-Berechnung im Quellcode von ebusd angeschaut - eigentlich genau das, was im Pseudo-Code im vorherigen Post zu finden ist.
Wichtige Erkenntnisse dabei: ein Lookup von 0x00 ergibt 0x00, die CRC Berechnung nur eines Bytes gibt als Ergebnis das Byte selbst zurück (bei einem Init-Wert von 0x00) und ein xor-verknüpfter Wert von 0x00 ändert den Lookup mit dem vorherigen Ergebnis nicht.
Dann habe ich festgestellt, dass der Wert an Position 1 der Lookup-Table dem CRC-Polynom selbst entspricht (was es noch zu beweisen gilt).
Berechnet man den CRC-Wert der zwei Bytes 0x01 und 0x00 kommt als Ergebnis der Lookup von 0x01 heraus, also das CRC-Polynom.
Dann habe ich einfach nur beim Dienst 5000 mit Länge+Adresse 0x0100 so lange das Check-Byte variiert, bis eine Antwort kam. Et voilá…
Dann habe ich festgestellt, dass der Wert an Position 1 der Lookup-Table dem CRC-Polynom selbst entspricht
Du bist ja gerissen, da wär ich nie draufgekommen!
Update der Tabelle mit allen Adressen und Adressblöcken, nun als zip.
Jetzt fehlt noch:
Wie sich der Befehl PB: 50 SB: 22 zusammensetzt
Prüfen ob der CRC mit dem Polynom auch für das Endanwender-Telegramm passt
Prüfen ob Adressen auch in den SYC Dateien drin sind
Prüfen welche Unterschiede zwischen den WTC-Versionen vorhanden sind
Schreibbefehl-Telegramme auflisten (sollte man vorsichtig sein)
Fällt dir noch was ein?
Ebus-Telegramme.xls.zip (67.4 KB)
Hab die SYC-Datei mal formatieren lassen und Übereinstimmungen gefunden, sieh selbst:
Datei:
26 user_b_K1_user_c_st.K1_i_zuendstrom_u8 59 E2 79
Tabelle:
E2 359 char % I25 Aktueller Zündstrom
E2 59 ist wohl die Adresse, nur die 3 fehlt?
Welche Datei braucht dein Gerät? Dann kann ich die dir mal formatiert geben.
Hallo geronet!
Ich habe herausgefunden, dass das Gerät WCM-CPU#1 WTC 15 und das Gerät WCM-WST die Datei 0002360.SYC verwendet.
Die Geräte FB#1 und FB#2 EM#2 (Heizkreisregler in der Fernbedienung) funktionieren auch ohne SYC-Datei.