-
-
Notifications
You must be signed in to change notification settings - Fork 360
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
Refactor nhs_ser
driver
#2715
Merged
jimklimov
merged 12 commits into
networkupstools:master
from
jimklimov:issue-2692-nhs-ser-refactor
Dec 12, 2024
Merged
Refactor nhs_ser
driver
#2715
jimklimov
merged 12 commits into
networkupstools:master
from
jimklimov:issue-2692-nhs-ser-refactor
Dec 12, 2024
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…stcmd and upsdrv_initinfo() Signed-off-by: Jim Klimov <[email protected]>
…d upsdrv_initups() [networkupstools#2692] Signed-off-by: Jim Klimov <[email protected]>
…indent main code a bit [networkupstools#2692] Fixed the retries from being an infinite loop along the way... Signed-off-by: Jim Klimov <[email protected]>
…a-stale related messages and status changes [networkupstools#2692] Signed-off-by: Jim Klimov <[email protected]>
…f_needed() [networkupstools#2692] Signed-off-by: Jim Klimov <[email protected]>
Signed-off-by: Jim Klimov <[email protected]>
Signed-off-by: Jim Klimov <[email protected]>
…packet data interpretation; un-indent more code [networkupstools#2692] Add range-check to not overflow the datapacket[] buffer. Signed-off-by: Jim Klimov <[email protected]>
…winfo() and interpret_pkt_data() logic, separated by domain [networkupstools#2692] Also rename some data points that do not conform to NUT standards, or drop if redundant. Signed-off-by: Jim Klimov <[email protected]>
…t complete names Signed-off-by: Jim Klimov <[email protected]>
…at and min_input_power in static vars [networkupstools#2692] Signed-off-by: Jim Klimov <[email protected]>
…ls#2692] Signed-off-by: Jim Klimov <[email protected]>
jimklimov
added
need testing
Code looks reasonable, but the feature would better be tested against hardware or OSes
refactor/fightwarn
PR or issue proposal to improve code maintainability without functional changes, or to fix warnings
serial port
labels
Dec 9, 2024
✅ Build nut 2.8.2.2508-master completed (commit 54b7097b94 by @jimklimov) |
CC @Challado - gentle bump, now that CI has passed. |
Jimmy, good morning. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
need testing
Code looks reasonable, but the feature would better be tested against hardware or OSes
refactor/fightwarn
PR or issue proposal to improve code maintainability without functional changes, or to fix warnings
serial port
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Follows up from #2692
CC @Challado - testing on HW would be welcome, to make sure nothing got broken by this reshuffle
Is my understanding correct that in your code, the first call to
upsdrv_updateinfo()
would read nothing good from the wire and have no good checksums in "last" packet structs, so it would issue calls at the end of the method ("pkt_hwinfo loss -- Requesting") to get the HW info (and you mentioned there may be a couple of seconds before it replies - so the next cycle viamain.c
picks up that bit-stream)? Does this also trigger appearance of Data packet readings, or does the UPS just regularly send those?Here the primary change was moving the code around for conformance to NUT driver design and general maintainability - primarily reduced indention level and improved readability by cutting large code of
upsdrv_updateinfo()
into methodsreconnect_ups_if_needed()
,interpret_pkt_hwinfo()
andinterpret_pkt_data()
which now deal each with one aspect of the work, to not repeat everything every time regardless of what was read.Some actual or suspected bugs were also addressed:
upsdrv_updateinfo()
: possible overflow of the packet buffer if the end character never comes (e.g. noise on serial cable)upsdrv_updateinfo()
: changed reconnection approach, now using datastale/dataok flags; this is one part where testing is importantupsdrv_initinfo()
toupsdrv_initups()
to match NUT init approachupsdrv_update()
belongs really in init, to be read/set once (that is still TODO).nut-names.txt
(and redundant vs. correct names) - testing welcome that nothing got lost except "wrong" aliases to same dataOther changes:
porta[PATH_MAX]
size more pedanticallysize_t
notint
experimental.nhs.*
datapoints which effectively dump the struct fields are now also populated only if corresponding debug options are set, so by default only the NUT standard names (in their domains likedevice
,ups
,input
andoutput
) should be seen."input.voltage.low.warning"
et al were set fromcalculated
variable that was never changed, fixed tovin_low_warn
etc.A couple of data dumps with and without the special debug options would be welcome for reference :)