[Nut-upsdev] Issue with On Line Status (APC MGE Galaxy 5500 + AP9635CH)

[Jim Klimov]

Glad to hear it! I suppose mib2nut tables may support a similar use-case,
where you would mark the expected data type (e.g. SU_TYPE_INT in bitmap vs.
plain SU_FLAG_OK) and use a conversion helper function with your custom
logic (last field in the table, typically NULL). This way you would define
several ways to query for "ups.status", whichever works, and that would be
up-streamable as a PR to NUT so you don't have to maintain the difference
locally :)

Jim

On Thu, Mar 30, 2023 at 4:30 PM mateuszx <jasmati09 at gmail.com> wrote:

> 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 <jimklimov+nut at gmail.com> 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 <jasmati09 at gmail.com> 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 <jasmati09 at gmail.com> 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 <jasmati09 at gmail.com> 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 <jasmati09 at gmail.com> 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 <
>>>>>> nut-upsdev at alioth-lists.debian.net> 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 <gdt at lexort.com> wrote:
>>>>>>>
>>>>>>>> mateuszx via Nut-upsdev <nut-upsdev at alioth-lists.debian.net>
>>>>>>>> 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
>>>>>>>> Nut-upsdev at alioth-lists.debian.net
>>>>>>>> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev
>>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Nut-upsdev mailing list
>>>>>>> Nut-upsdev at alioth-lists.debian.net
>>>>>>> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev
>>>>>>>
>>>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/nut-upsdev/attachments/20230330/d67669b8/attachment-0001.htm>