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.
Beitrag #6979581 wurde von einem Moderator gelöscht.
Mega-Krass. Echt schlimm. Gibt es dazu noch etwas an Informationen ? Worum geht es und und woher ist dein Wissen, dass etwas nicht stimmt ?
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 };
:
Bearbeitet durch User
Pepe T. schrieb: > for (int k=1;k<14;k++) Dass da überhaupt was stimmt, wenn du immer das erste Byte vergisst.
Beitrag #6979623 wurde von einem Moderator gelöscht.
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
Beitrag #6979692 wurde von einem Moderator gelöscht.
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.
Also eins steht fest, mit low IQ Aussagen solltest du dich bei diesem Thread hier lieber zurückhalten.
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.
Beitrag #6979727 wurde von einem Moderator gelöscht.
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
Pepe T. schrieb im Beitrag #6979692:
> direkte auswirungen
sag mal, hast du öfters Syntax Error in deinen Programmen?
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.
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; }
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ß
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
:
Bearbeitet durch User
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.
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.
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.
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.
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 ;-)
Patrick L. schrieb: > eine FIFO als Zwischenspeicher Einen 2 kern esp32 ... ein kern macht dann fifo :)
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.
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.