Upstream Eaton/Powerware/MGE data mappings from 42ity/nut #1319
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
….h and apc-mib.c and snmp-ups.c
…arlin-mib.c to eaton-pdu-marlin-helpers.c/.h
…ebases that support these callbacks from those that currently do not
Signed-off-by: Jim Klimov <[email protected]>
… a full solution - some mapping functions are needed and revision of MIB data types)
…ement conversion func for "outlet.group.%i.phase"
…ement conversion func for "device.count" which returns a comma-separated list
Also update line-breaks for readability and 80-col standard
Solution: Attach 1 feed to the current input Signed-off-by: Arnaud Quette <[email protected]>
…ip, and daisychain implications
Signed-off-by: Arnaud Quette <[email protected]>
Remove the not needed SU_FLAG_UNIQUE and the erroneous value lookup structure index Signed-off-by: Arnaud Quette <[email protected]>
Add support for shutdown and start timers Signed-off-by: Arnaud Quette <[email protected]>
Fix data name, since the published value is in Watts, so realpower, not power Signed-off-by: Arnaud Quette <[email protected]>
Signed-off-by: Arnaud Quette <[email protected]>
Add support for the 2 GPI accessible through EMP001 environmental sensor, connected to a UPS or ATS16. The same is already available for Eaton ePDU. This affect the snmp-ups driver (eaton_ats16 and pw/pxgx_ups MIBs), and the netxml-ups driver Signed-off-by: Arnaud Quette <[email protected]>
While "open" is the best adjective for the opposite of "closed", and thus suitable for GPI status, this may lead to confusion with the GPO actions "open|close" Vs the GPI status "opened|closed". These last are also not inapropriate, since they can refer to the fact that the GPI state has change due to some external action or event Signed-off-by: Arnaud Quette <[email protected]>
…pping structure" changes for input.phases=>input.count
* duplicate some OIDs, with refinement to point at the first index (i.e ".0" or ".1.0") since otherwise the agent doesn't respond to queries. This could be fixed at the snmp-ups level later * fixed "ups.type" (power topology of the UPS) which was pointing at the output.source or ups.mode Signed-off-by: Arnaud Quette <[email protected]>
…nagement cards" (unused variable warning)
power and realpower for 3ph Lx were not publishing values when they were 0 Signed-off-by: Arnaud Quette <[email protected]>
Though there is output.Lx.power.percent, for 3phase, it's desirable to also have the standard ups.load Signed-off-by: Arnaud Quette <[email protected]>
Signed-off-by: Arnaud Quette <[email protected]>
…fo) when not WITH_SNMP_LKP_FUN
…mapping function Note: ported sub-set of "snmp-ups.[ch] : add support for extended fun/nuf l2s/s2l conversions and use it for daisychain initialization" without the actual 2x2 "fun/nuf l2s/s2l" support here.
|
Differences for a single UPS, between current upstream/NUT master branch and this PRed codebase, across several MIBs:
|
|
Daisychain "master" device (ePDU), between current upstream/NUT master branch and this PRed codebase: |
|
Daisychain "slave" device (ePDU with its own IP address), between current upstream/NUT master branch and this PRed codebase: |
|
This pull request introduces 1 alert when merging 2d97ab0 into a145477 - view on LGTM.com new alerts:
|
|
Differences between FTY branch (as bumped in 42ity#169 proposal) and this PR, these are of practical interest for "non-regression" to replace use of 42ity/nut with upstream NUT:
|
34 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
A large block of changes from #1316 upstreaming effort, this PR should cover most of the visible "non-DMF" improvements for snmp-ups driver itself, some code restructuring into helper files (in "full" DMF it allows easier reuse of some still needed binary code), as well as data mappings in Eaton/Powerware/MGE MIB files and mge-xml.c, most of which happened to not be cross-posted to 42ity/nut and upstream NUT (unlike many other changes that did land in both repos between 2015-2022).
It also adds the
SU_FLAG_SEMI_STATICdefinition and handling, and fixes daisy-chain init for devices with some MIBs.Compared to current state of 42ity/nut FTY branch, this fixes a few missed cases of "open" => "opened" contact status (similar fix is added in an open PR for resync from master, which also serves to minimize diffs of the two codebases).
hpeandraritansubdriver sources still mention"open"in both branches for something; should this be all brought to same standard?nut-names.txtand standardize some new concepts.Also compared to current state of 42ity/nut FTY branch, this (possibly clumsily) drops or stubs the DMF support (e.g.
WITH_SNMP_LKP_FUNmacro is used in some but not all places to simplify later diffs, but by definition insnmp-ups.hit is currently effectively always defined, since DMF macros for the other possibility are not in scope yet), and the loosely related extension to the classes of mapping functions (bumping from 2 to 4 pointers) is not ported since so far there were very few use-cases for that flexibility and they were wrought into existing code structure for now.Practical diffs in device walks across builds would be posted in comments below.