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.
Und ich hab gerade herausgefunden, daß die nächste Gerätegeneration der WTC Gasgeräte (ist noch nicht zu kaufen) keinen Ebus mehr hat sondern einen Netzwerkanschluß (Ethernet). Die Heizkreismodule/Fernbedienungen werden per CAN-Bus verbunden… 
Hier mal die Datei, mit einem C-Programm formatiert und in Tabelle kopiert. Vielleicht wirst du daraus schlau?
2360.xls (110 KB)
Wenn du mal Zeit hast, vergleich doch die Adress-Spalte in der Ebus-Tabelle mit deinen. Da müssen Übereinstimmungen dabei sein.
Hallo geronet
Die Tabelle hab ich mal überflogen - ich habe auf den ersten Blick leider keine Adresse gefunden - beispielsweise hab ich nach denen aus der Errorhistory gesucht…
…aber ich war auch mit den Gedanken bei etwas anderem!
Ich habe ein Shell-Script entwickelt, das das Check-Byte berechnet.
Siehe https://forum.fhem.de/index.php/topic,61017.msg560991.html#msg560991
Hallo geronet, hallo Welt!
Ich habe mich mit dem Fehlerspeicher des WTC beschäftigt und die Nachrichtendefinitionen für ebusd überarbeitet.
Es ist mir gelungen, die Nachrichtendefinitionen so zu verketten, dass ein einziger aufruf des ebusctl-Kommandos genügt, um den kompletten Fehlerspeicher auszulesen.
Siehe https://forum.fhem.de/index.php/topic,61017.msg561536.html#msg561536
Dabei bin ich auch zu der Erkenntnis gekommen, dass der erste Wert des ersten Telegramms für die Fehlerhistorie nicht die Anzahl der Fehler im Speicher ist, sondern der Offset zum ersten Fehlereintrag innerhalb des Ringpuffers!
Hallo J0K3r, das mit dem Offset kann ich leider nicht bestätigen, bei beiden Geräten.
Die Anzahl der Fehler im Speicher steht bei mir an Block 06 02, Adresse 2BC und bei dem WTC32 an Block 06 01, Adresse 23C. Wenn man den Fehlerspeicher zurücksetzt, kommt da auch eine 0. Scheint wohl bei jeder Version anders zu sein?
Ich implementiere grade die Telegramme und stricke sie nach den Adressabfragen selbst zusammen, welche Werte ich brauche. Funktioniert super und hast du gut herausgefunden, kann man dir einen ausgeben?
Habs grad mit dem Fehlerspeicher nochmal gecheckt, du hast Recht!
Aber die erste Zahl die er abfrägt ist kein Offset als Speicheradresse sondern die letzte Fehlerposition im Ringpuffer. Kommt ein neuer Fehler rein liest er die Zahl und überschreibt den nächsten (also den ältesten) Fehler und inkrementiert die Zahl um 1.
Somit muss man den Fehlerspeicher komplett auslesen, nach der laufenden Nummer ist das dann der jüngste und die rückwärts jeweils die älteren :rolleyes:
Beim Fehlerspeicher-Rücksetzen schreibt er mit Kommando 50 01 über alle Fehler 0 drüber.
Ist ganz schön umständlich und aufwendig, da mein Fehlerspeicher über zwei Blöcke verteilt ist (06 01 und 06 02) und das noch irgendwo mittendrin…
Hallo geronet!
Ich verfeinere gerade meine Nachrichten-Definitionen.
Hast Du zufällig das 500A-Telegramm entschlüsselt, das vom Heizungsregler per Broadcast in den eBus gefeuert wird?
Speziell interessiert mich das erste Byte - bei mir Status 1 - , das dritte Byte - ich nenn es Status 2 - und das vierte Byte - Status 3.
Das zweite Byte ist vermutlich die Betriebsphase.
Die gesuchten Status-Bytes sind wohl Bit-codiert.
Meine Vermutung für die Bitbelegung für Status 2 sieht so aus:
Bit 0 - ?
Bit 1 - ?
Bit 2 - ?
Bit 3 - Flamme
Bit 4 - Gasventil 1
Bit 5 - Gasventil 2
Bit 6 - Pumpe
Bit 7 - Fehler-Bit
Viele Grüße
J0K3r
Hi JOK3r, 50 0A sendet meiner auch alle 30 sek.
Byte 0 weiß ich nicht.
Byte 1 ist die Betriebsphase bzw. Fehler
Byte 4 ist ein d1c Wert (Vorlauftemperatur)
Grad gefunden, du hast es selber schon rausgefunden:
Weishaupt WTC am eBus mit ebusd
Hab jetzt eine zweite ebus-Platine gelötet und in meinen Regler eingebaut. Muss nur noch die Software bisschen verbessern (z.b. Fehlermeldung bei Verbindungsabbruch) und dann läuft die Sache
Was anderes ist mir auch aufgefallen, zum testen hab ich öfters mal die Adresse vom Kessel geändert.
Bei 1 (Einzelkessel) schickt er das 500A Telegramm an Broadcast…
Bei A-D schickt er ein ähnliches Telegramm gezielt an Adresse 0x10, das ist dann der Kaskadenmanager.
Wenn man dem Kessel einen Sollwert mit 0507 schickt, muss man das spätestens alle 10 min machen sonst kommt Fehler W80 (Kommunikation zum Kaskadenmanager oder WCM-Sol fehlerhaft) oder W81 je nach dem welche Adresse man verwendet zum senden.
Wenn ich auf dieses Thema zurückblicke, bin ich mir nicht sicher, ob es Ihnen letztendlich gelungen ist, eBus-Schreibvorgänge durchzuführen (falls kein WCM-FB vorhanden war)
@geronet, ich habe gesehen, dass Sie bei Ihren Tests kein WCM-FB verwendet haben.
Danke!