Checksummenberechnung. Versteh's nicht.

[Pepe T. (pepe_t)]

Flogendes messages:
0xD0, 0x03, 0x16, 0x00, 0x05, 0x00, 0x00, 0x00, 0x28, 0x32, 0x00, 0x0A, 
0x05, 0x23, 0xAA
0xD2, 0x32, 0x28, 0x2D, 0x03, 0x0D, 0xA0, 0xAF, 0x28, 0x32, 0x00, 0x0A, 
0x05, 0x23, 0x72
0xDD, 0x15, 0x30, 0x14, 0x12, 0x12, 0x00, 0x00, 0x00, 0x32, 0x00, 0x0A, 
0x05, 0x23, 0xE1
checksum ist leztes byte, die 8 bit summe von byte 1 bis 13. Klappt auch 
schön. Aber bei denen:
0xD9, 0x04, 0x46, 0x08, 0x5A, 0x50, 0x46, 0x00, 0x00, 0x07, 0x00, 0x00, 
0x40, 0x03, 0x8D
0xD9, 0x04, 0x46, 0x08, 0x5A, 0x50, 0x46, 0x00, 0x00, 0x07, 0x00, 0x00, 
0x4C, 0x03, 0x99
ist die berechnete checksumme eins niedriger als das lezte byte.
Und bei denen:
0x33, 0xCD, 0xD7, 0xD2, 0xFC, 0xF2, 0x5F, 0x11, 0xD7, 0xCD, 0xFF, 0xF5, 
0xFA, 0xDC, 0x4E
0x33, 0xCD, 0xD7, 0xD2, 0xFC, 0xF2, 0x5F, 0x51, 0xD7, 0xCD, 0xFF, 0xF5, 
0xFA, 0xDC, 0x8E
0x3F, 0xFC, 0xE9, 0xFF, 0xFA, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 
0xFF, 0xFF, 0xE1
ist die checksummn 0x0C niedriger als das letzte byte.
Ich versteh das nicht.

[Purzel H. (hacky)]

Mega-Krass. Echt schlimm.
Gibt es dazu noch etwas an Informationen ?
Worum geht es und und woher ist dein Wissen, dass etwas nicht stimmt ?

[Pepe T. (pepe_t)]

Berechnen möcht ich das weil es manchmal zu falschdaten kommt. Siehe 
bild.
Pulseview scan des 1-wire busses ist angehängt.

Purzel H. schrieb:
> Gibt es dazu noch etwas an Informationen ?
Beitrag "Kennt jemand diese WarmwasserWärmepumpe?"

Purzel H. schrieb:
> Worum geht es und und woher ist dein Wissen, dass etwas nicht stimmt ?
Das lezte byte stimmt nicht mit der berechnung überein.

die hier:
uint8_t chksum(uint8_t * msg)
{
  uint8_t chks=0;
  for (int k=1;k<14;k++)
    chks += msg[k];
  return chks;
}

mit den datensäzen:
uint8_t wpmsg0[15] = {0xD0, 0x03, 0x16, 0x00, 0x05, 0x00, 0x00, 0x00, 
0x28, 0x32, 0x00, 0x0A, 0x05, 0x23, 0xAA };
uint8_t wpmsg2[15] = {0xD2, 0x32, 0x28, 0x2D, 0x03, 0x0D, 0xA0, 0xAF, 
0x28, 0x32, 0x00, 0x0A, 0x05, 0x23, 0x72 };
uint8_t wpmsg9[15] = {0xD9, 0x04, 0x46, 0x08, 0x5A, 0x50, 0x46, 0x00, 
0x00, 0x07, 0x00, 0x00, 0x40, 0x03, 0x8D };
uint8_t wpmsgx[15] = {0xD9, 0x04, 0x46, 0x08, 0x5A, 0x50, 0x46, 0x00, 
0x00, 0x07, 0x00, 0x00, 0x4C, 0x03, 0x99 };
uint8_t wpmsgD[15] = {0xDD, 0x15, 0x30, 0x14, 0x12, 0x12, 0x00, 0x00, 
0x00, 0x32, 0x00, 0x0A, 0x05, 0x23, 0xE1 };
uint8_t wpmpon[15] = {0x33, 0xCD, 0xD7, 0xD2, 0xFC, 0xF2, 0x5F, 0x11, 
0xD7, 0xCD, 0xFF, 0xF5, 0xFA, 0xDC, 0x4E };
uint8_t alloff[15] = {0x33, 0xCD, 0xD7, 0xD2, 0xFC, 0xF2, 0x5F, 0x51, 
0xD7, 0xCD, 0xFF, 0xF5, 0xFA, 0xDC, 0x8E };
uint8_t filler[15] = {0x3F, 0xFC, 0xE9, 0xFF, 0xFA, 0xFF, 0xFF, 0xFF, 
0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xE1 };

[Mario M. (thelonging)]

Pepe T. schrieb:
> for (int k=1;k<14;k++)

Dass da überhaupt was stimmt, wenn du immer das erste Byte vergisst.

[Pepe T. (pepe_t)]

Zur erklärung de pulseview files:
9ms lo 5ms hi ist sync.
dann ist 3ms hi = 0, 1 ms hi = 1, getrennt immer mit 1ms lo.

Da sprechen 2 geräte mit etwas unterschiedlichem timing.
Die 0xDX ist die WP, die 0x3X ist tastatur/display

[Nosnibor (Gast)]

Das erste Byte auszulassen scheint schon richtig zu sein.

Kann es sein, dass man den Überlauf bei der 8-bit-Addition noch 
dazurechnen muss?
Das kommt in vielen Prüfsummenvorschriften vor, ist gelegentlich (z.B. 
in 6502-Assembler) geringfügig einfacher zu implementieren, hat aber 
wahrscheinlich auch irgendwelche mathematischen Gründe.
Also: chks als uint16_t deklarieren und am Ende chks + (chks>>8) 
zurückgeben.

[Dieter D. (dieter_dosenkohl)]

Also eins steht fest, mit low IQ Aussagen solltest du dich bei diesem 
Thread hier lieber zurückhalten.

[Pepe T. (pepe_t)]

Nosnibor schrieb:
> Also: chks als uint16_t deklarieren und am Ende chks + (chks>>8)
> zurückgeben.

Das stimmt bei drei mit überlauf und bei all denen ohne überlauf.
Und das ist 3 mal falsch.

[tja (Gast)]

am einfachsten wäre natürlich, wenn der TO verraten würde, welchen 
Sensor er verwendet. Idealerweise könnte er auf das Datenblatt 
verlinken. Und wenn heute Weihnachten wäre, würde er die entsprechenden 
Stellen rauskopieren, wo beschrieben ist wie ein Datenpaket aussieht und 
wie der Algorithmus der Prüfsummenberechnung aussieht. Aber ich weiß, 
das wäre deutlich zuviel verlangt... träum

[Schupo (Gast)]

Nimm einen Taschenrechner und überprüfe das Ergebnis.

[Gunnar F. (gufi36)]

Pepe T. schrieb im Beitrag #6979692:
> direkte auswirungen

sag mal, hast du öfters Syntax Error in deinen Programmen?

[Wühlhase (Gast)]

Pepe T. schrieb im Beitrag #6979692:
> Oder weil ich dir bewusst gemacht habe dass die derzeitige ultra-low-IQ
> einwanderung  direkte auswirungen auf steuerlast, lohnprozente, mietzins
> und sicherheit deiner freundin / tochter haben wird?

Tut mir leid fürs Abschweifen, aber echt - DIESER Pepe willst du sein? 
Hehe...

Ansonsten würde ich dein k mal mit 0 anstelle von 1 initialisieren - und 
warum zählst du nur 14 Bytes zusammen? Immerhin sind deine Nachrichten, 
die du als Demodaten gepostet hast, samt und sonders ungleich 14 Bytes 
lang.

[Pepe T. (pepe_t)]

habs mir einfach gemacht ... Brauch eh nur die DX messages.

uint8_t chksum(uint8_t * msg)
{
  uint8_t chks=0;
  for (int k=1;k<14;k++)
    chks += msg[k];
  if (msg[0] == 0xD9) chks++;
  return chks;
}

[Stefan (Gast)]

Hallo,

die verwendete Berechnung deiner Prüfsumme ist aus den IP-Protokollen 
entliehen!

Du musst die 16bit-Summe aus den Byte [1] bis [12} bilden und zum 
Schluss das High-Byte zum Low-Byte addieren!
Im Folgenden deine Daten, alles Hex
chk ist die 16bit-Summe, chk1 ist High-Byte+Low-Byte

03,16,00,05,00,00,00,28,32,00,0a,05,23,aa, chk=00aa, chk1=aa,
32,28,2d,03,0d,a0,af,28,32,00,0a,05,23,72, chk=0272, chk1=74,  *
15,30,14,12,12,00,00,00,32,00,0a,05,23,e1, chk=00e1, chk1=e1,
04,46,08,5a,50,46,00,00,07,00,00,40,03,8d, chk=018c, chk1=8d,
04,46,08,5a,50,46,00,00,07,00,00,4c,03,99, chk=0198, chk1=99,
cd,d7,d2,fc,f2,5f,11,d7,cd,ff,f5,fa,dc,4e, chk=0a42, chk1=4c,  *
cd,d7,d2,fc,f2,5f,51,d7,cd,ff,f5,fa,dc,8e, chk=0a82, chk1=8c,  *
fc,e9,ff,fa,ff,ff,ff,ff,ff,ff,ff,ff,ff,e1, chk=0cd5, chk1=e1,

Bei Zeilen mit * Daten nochmal überprüfen!

Gruß

[Stefan (Gast)]

Hallo, Nachtrag
statt [12} muss es heissen [13]

[Pepe T. (pepe_t)]

03,16,00,05,00,00,00,28,32,00,0a,05,23,aa, chk=00aa, chk1=aa,    > aa
32,28,2d,03,0d,a0,af,28,32,00,0a,05,23,72, chk=0272, chk1=74,  * > 72
15,30,14,12,12,00,00,00,32,00,0a,05,23,e1, chk=00e1, chk1=e1,    > e1
04,46,08,5a,50,46,00,00,07,00,00,40,03,8d, chk=018c, chk1=8d,    > 8d
04,46,08,5a,50,46,00,00,07,00,00,4c,03,99, chk=0198, chk1=99,    > 99
cd,d7,d2,fc,f2,5f,11,d7,cd,ff,f5,fa,dc,4e, chk=0a42, chk1=4c,  * > 4e
cd,d7,d2,fc,f2,5f,51,d7,cd,ff,f5,fa,dc,8e, chk=0a82, chk1=8c,  * > 8e
fc,e9,ff,fa,ff,ff,ff,ff,ff,ff,ff,ff,ff,e1, chk=0cd5, chk1=e1,    > e1

Die mit dem * stimmen nicht. Da ist irgendwas anders.
Hab die sollwerte nach dem > hingeschrieben.

Die temperaturanzeige geht auch ohne :)
Rot oben im tank (auslauf), grün unten im tank (einlauf), blau WP an/aus

[Thomas (kosmos)]

du könntest aber auch Abweichungen zum Vorwert großer x einfach 
ignorieren.

Es ist ja recht unwahrscheinlich das ein Analoger Sensor etwas wie 127, 
128, 127, 125, 123, 0 , 123, 124,....ausspuckt.

[Pepe T. (pepe_t)]

Glücklicherweise haben die 2 messages die ich brauche die korrekte CS. 
Die andern ignorier ich einfach. Scheint zu klappen.
Die fehler kommen wenn der chip mit dem webserver beschäftigt ist und 
keine zeit für's einlesen hat.

[Patrick L. (Firma: S-C-I DATA GbR) (pali64)]

Warum nicht mit einem Checksumm verifizieren und bei Fehler nochmals 
senden?

Bei dem Steinzeit MOD-BUS ist das gang und gebe, das mann ein Bytepaket 
nochmals sendet wen kein OK zurückkommt ;-)
Grad wenn du sagst das Bytes verloren gehen, bietet sich das doch an?

Ich weis MOD-BUS ist stein alt, aber wird in OP's heute noch immer 
verwendet, wohl nicht grundlos.

[Pepe T. (pepe_t)]

Patrick L. schrieb:
> Warum nicht mit einem Checksumm verifizieren und bei Fehler nochmals
> senden?

Ich höre hier nur mit, ich kann nicht beeinflusset was gesendet wird. 
Die WP sendet aber alle 4 sekunden alle daten, also ist ein 
einzelausfall kein problem.

[Patrick L. (Firma: S-C-I DATA GbR) (pali64)]

Pepe T. schrieb:
> Ich höre hier nur mit,

Dan wäre höchstens noch eine FIFO als Zwischenspeicher eine Möglichkeit, 
dann kannst du dort das ohne Verlust abhohlen ;-)

[Pepe T. (pepe_t)]

Patrick L. schrieb:
> eine FIFO als Zwischenspeicher

Einen 2 kern esp32 ... ein kern macht dann fifo :)

[Pepe T. (pepe_t)]

Läuft so bestens. Das sind die letzten 24 stunden. 3 mal haben die 
frauen geduscht. Knapp 30 min solarbetrieb heute, rest nachtstrom 
12ct/kwh.