Well thanks, The solution for my problem was kinda easy (still need some testing though): found out my ups status is a string, so then I changed the way snmp-ups.c gets the status. Had to change *nut_snmp_get_int *to *nut_snmp_get_str *at around line 3470, then grab fourth char out, use *strtol *function to then send it to *su_status_set *function. I created my copy of *apc-mib.c *with my OID at place, then did cases for 0/1 values and Voilà! (I know I probably need some if's there so other non-string-status UPS's would work with my config but I'm happy nonetheless :))
Matthew śr., 29 mar 2023 o 13:31 Jim Klimov <[email protected]> napisał(a): > One good intro to this is > https://github.com/networkupstools/nut/blob/master/docs/snmp-subdrivers.txt > although it focuses on adding new subdrivers - but more or less the same > workflow applies to extending existing ones. Sometimes it helps to generate > a new one for a currently-partially-supported device, and then compare with > existing subdriver (using meld or similar GUI helps a lot) to port the > missing lines into it. > > In computers all numbers are binary :) In SNMP they should be Integer32 or > Integer64 type, I think. Do you know which APC MIB version that NMC > supports, and if that MIB's text contradicts the reality (an APC bug to > report to them, I guess). > > In the nut2mib structures you can specify several sources for the same > reading name, which allows the same subdriver to "pick the keys" to > different generations of otherwise similar devices. The first (or was it > last?) hit in the table wins, IIRC, so if an actual device exposes some > data in several OIDs (e.g. with different-precision data types, like in > vendor-extended vs. IETF-standard MIBs), the preference ordering may matter. > > Jim > > > On Mon, Mar 27, 2023 at 2:01 PM mateuszx <[email protected]> wrote: > >> So what would it take me to edit NUT's code for my case to work? My >> Network Management Card sends its output state using unfortunately only (I >> guess so) this OID: 1.3.6.1.4.1.318.1.1.1.11.1.1.0 >> Weirdly the standard way of obtaining Battery Status (drivers/apc-mib.c) >> 1.3.6.1.4.1.318.1.1.1.2.1.1.0 >> gives me good results. >> Unfortunately power status OID's value type differs (my: 64 digits binary >> number vs standard: integer). >> I know i can retrieve each bit's value with no problem but the question >> is: How do I integrate my bit recognition with NUT's nut2mib struct and so >> on... >> I am working on drivers/apc-mib.c UPS driver >> Maybe is there something relatable already in the code so I can "make my >> work easier"? >> >> Matthew >> >> czw., 9 mar 2023 o 16:00 mateuszx <[email protected]> napisał(a): >> >>> I've got an update on this case >>> Using tkmib I discovered that my UPS (NMC per say) sends its state by >>> OID 1.3.6.1.4.1.318.1.1.1.11.1.1.0 >>> .iso.org.dod.internet.private.enterprises.apc.products.hardware.ups.upsState.upsBasicState.upsBasicStateOutputState.0 >>> = 0001010000000000001000000000000000000000000000000000000000000000 >>> (mib used for this snmpget was powernet441.mib) >>> (I got a description about each bit here, 4th bit is for OnLine, 6th >>> stands for Serial Communication Established, 19th is "On") >>> >>> Then I ran tcpdump grepping for this kind of OID. First using >>> snmpget/snmpwalk, then using upsc asking for ups.status or the entire upsc >>> output. >>> I've included tcpdump logs as well as the description of OID I've found. >>> >>> My question: is getting ups.status about changing "a few lines of code" >>> in let's say apc-mib.c file in the drivers folder of the repo or I should >>> make a commit and code ups.status depending on bits received using this OID? >>> I am running NUT 2.8.0 at the moment. >>> >>> czw., 9 mar 2023 o 14:14 mateuszx <[email protected]> napisał(a): >>> >>>> I've got an update on this case >>>> Using tkmib I discovered that my UPS (NMC per say) sends its state by >>>> OID 1.3.6.1.4.1.318.1.1.1.11.1.1.0 >>>> .iso.org.dod.internet.private.enterprises.apc.products.hardware.ups.upsState.upsBasicState.upsBasicStateOutputState.0 >>>> = 0001010000000000001000000000000000000000000000000000000000000000 >>>> (mib used for this snmpget was powernet441.mib) >>>> (I got a description about each bit here, 4th bit is for OnLine, 6th >>>> stands for Serial Communication Established, 19th is "On") >>>> >>>> Then I ran tcpdump grepping for this kind of OID. First using >>>> snmpget/snmpwalk, then using upsc asking for ups.status or the entire upsc >>>> output. >>>> I've included tcpdump logs as well as the description of OID I've found. >>>> >>>> My question: is getting ups.status about changing "a few lines of code" >>>> in let's say apc-mib.c file in the drivers folder of the repo or I should >>>> make a commit and code ups.status depending on bits received using this >>>> OID? >>>> I am running NUT 2.8.0 at the moment. >>>> >>>> Matthew >>>> >>>> >>>> czw., 2 mar 2023 o 10:46 mateuszx <[email protected]> napisał(a): >>>> >>>>> NUT version is 2.7.4-14ubuntu2 indeed. >>>>> I think my next step will be examining data sent over SNMP, because >>>>> I've recently spotted some more problems with my device and so I will try >>>>> contacting APC for those reasons. >>>>> Anyway thanks for the output, I really appreciate it >>>>> >>>>> Matthew >>>>> >>>>> wt., 28 lut 2023 o 13:29 Jim Klimov via Nut-upsdev < >>>>> [email protected]> napisał(a): >>>>> >>>>>> Also, which version of NUT is involved? There were recently PRs >>>>>> (merged to master-branch, eventually will be in 2.8.1) about more >>>>>> SNMP-UPS >>>>>> support including APCs e.g. 1674, 1679, 1113 (should be in 2.8.0)... >>>>>> >>>>>> Many distros still ship 2.7.4... >>>>>> >>>>>> Jim >>>>>> >>>>>> On Tue, Feb 28, 2023, 00:57 Greg Troxel <[email protected]> wrote: >>>>>> >>>>>>> mateuszx via Nut-upsdev <[email protected]> writes: >>>>>>> >>>>>>> > At my workplace I have exact UPS config as stated in the subject >>>>>>> (APC MGE >>>>>>> > Galaxy 5500 + AP9635CH). >>>>>>> > I have it set up to work with snmp-ups NUT driver. >>>>>>> > Despite many readings from *upsc* command I am not receiving "On >>>>>>> Line >>>>>>> > Status" (ups.status OL) nor "On Battery Status" (ups.status OB) and >>>>>>> > therefore I can't get my systems to shutdown during a power outage >>>>>>> event. >>>>>>> > (device and ups) Serial Number seems to be missing too in both >>>>>>> *upsc *AND Web >>>>>>> > Interface of Network Management Card. >>>>>>> > It can read battery charge just fine (it can even trigger Low >>>>>>> Battery >>>>>>> > Status!). >>>>>>> > When I unplug the UPS from line power it does indeed log this >>>>>>> event on the >>>>>>> > Web Interface. >>>>>>> >>>>>>> I would run tcpdump and record and examine the SNMP traffic, and >>>>>>> turn on >>>>>>> debugging in the driver. It is likely that the SNMP queries for >>>>>>> status >>>>>>> are not doing what the driver author expected. You'll have to find >>>>>>> out >>>>>>> if your UPS has different variables. snmpwalk may also be useful, or >>>>>>> docs. >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Nut-upsdev mailing list >>>>>>> [email protected] >>>>>>> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev >>>>>>> >>>>>> _______________________________________________ >>>>>> Nut-upsdev mailing list >>>>>> [email protected] >>>>>> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev >>>>>> >>>>>
_______________________________________________ Nut-upsdev mailing list [email protected] https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev
