-
-
Notifications
You must be signed in to change notification settings - Fork 69
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Properly handle VE.Direct fragmentation #814
Conversation
@bikerbiker12 @SW-Niko Könnt ihr bitte die Firmware aus dem PR Build Run testen? Einfach die passende Variante herunterladen und die .bin Datei aus dem ZIP-Archiv als Firmware-Update hochladen.
Das sollte mit diesem PR gelöst sein. |
queue every text event until the frame was checked by it checksum. then process the data directly into the buffer struct. do not clear the buffer struct, so it will always include the most recent value of a particular data point.
hand out const& to the data structs. this is possible now that this struct is "stable", i.e., not reset regularly.
Hallo zusammen, Habe eben die Firmware aus dem PR Build Run per OTA erfolgreich aufgespielt und werde es mal beobachten. Aktuell kann ich berichten, dass nun alle Werte ohne Wechsel angezeigt werden. Liebe Grüße Marco |
@bikerbiker12 Vielen Dank fürs Testen und deine Rückmeldung!
Ja, damit darfst du rechnen. |
31cea34
to
5fa04f9
Compare
Mir ist nichts negatives aufgefallen aber .... |
double precision floating point numbers are not needed to handle VE.Direct values. handling double is implemented in software and hence *much* more resource intensive.
the use of a #define is warranted here since it saves a lot of code duplication and improves code readability.
5fa04f9
to
7a9a934
Compare
Das sehe ich anders, das heißt nämlich zumindest, dass du keine Regression gefunden hast 😊 Ich habe mir einen bestehenden Emulator umgebastelt um "gesplittete Nachrichten" zu schicken, und damit konnte ich plausibel machen, dass der Ansatz taugt. Und Marco bestätigt das auch im Betrieb an seinem echten Laderegler. |
@schlimmchen - Perfekt, funktioniert auch hier super. 1000 Dank! Nur als Gedankenspiel - die Systeme die hier gerade im Aufbau sind, haben alle 2 oder noch mehr Victrons. Bisher benötigt man für mehrere Victrons (die günstigere variante ohne eigenem CAN Bus), einen eigenen ESP mit OpendtuOB und muss dann im node red zusammen rechnen. Vielleicht ist es ja ein Klax, mehrere Victrons vorzusehen. Die Baupläne der Anlage gebe ich dir für den Projekt-Bereich sobald alles durch ist =) |
Danke für die Rückmeldung.
Meinst du vielleicht #706 (bereits veröffentlicht) und #833? Nein, das war kein Klacks, und es waren drei Entwickler beteiligt, aber ich glaube es gibt jetzt keinen Grund mehr jeden Laderegler mit einem einzelnen OpenDTU-OnBattery zu koppeln. Schlimmstensfalls einer pro Paar (wenn man alle Daten haben möchte) oder einer pro VE.Smart Netzwerk, wenn es "nur" darum geht die Leistung für den DPL zu berücksichtigen. |
Wow seid ihr fix! Ja genau darum geht es - nochmals 1000 Dank & grossartige Arbeit! |
This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new discussion or issue for related concerns. |
Closes #774 and #689.