<div dir="ltr"><div>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 :)</div><div><br></div><div>Jim<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Mar 30, 2023 at 4:30 PM mateuszx <<a href="mailto:jasmati09@gmail.com">jasmati09@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Well thanks,</div><div>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. <br></div><div>Had to change <i>nut_snmp_get_int </i>to <i>nut_snmp_get_str </i>at around line 3470, then grab fourth char out, use <i>strtol </i>function to then send it to <i>su_status_set </i>function.</div><div>I created my copy of <i>apc-mib.c </i>with my OID at place, then did cases for 0/1 values and Voilà!</div><div>(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 :))</div><div><br></div><div><br></div><div>Matthew<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">śr., 29 mar 2023 o 13:31 Jim Klimov <<a href="mailto:jimklimov%2Bnut@gmail.com" target="_blank">jimklimov+nut@gmail.com</a>> napisał(a):<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>One good intro to this is <a href="https://github.com/networkupstools/nut/blob/master/docs/snmp-subdrivers.txt" target="_blank">https://github.com/networkupstools/nut/blob/master/docs/snmp-subdrivers.txt</a> 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.<br></div><div><br></div><div>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).</div><div><br></div><div>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.</div><div><br></div><div>Jim</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Mar 27, 2023 at 2:01 PM mateuszx <<a href="mailto:jasmati09@gmail.com" target="_blank">jasmati09@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>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: <span>1.3.6.1.4.1.318.1.1.1.11.1.1.0<br></span></div><div><span>Weirdly the standard way of obtaining Battery Status (drivers/apc-mib.c) </span>1.3.6.1.4.1.318.1.1.1.2.1.1.0 gives me good results.</div><div>Unfortunately power status OID's value type differs (my: 64 digits binary number vs standard: integer).</div><div>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...</div><div>I am working on drivers/apc-mib.c UPS driver <br></div><div>Maybe is there something relatable already in the code so I can "make my work easier"?</div><div><br></div><div>Matthew<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">czw., 9 mar 2023 o 16:00 mateuszx <<a href="mailto:jasmati09@gmail.com" target="_blank">jasmati09@gmail.com</a>> napisał(a):<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>I've got an update on this case</div><div>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</div><div>.iso.org.dod.internet.private.enterprises.apc.products.hardware.ups.upsState.upsBasicState.upsBasicStateOutputState.0 = 0001010000000000001000000000000000000000000000000000000000000000</div><div>(mib used for this snmpget was powernet441.mib)</div><div>(I got a description about each bit here, 4th bit is for OnLine, 6th stands for Serial Communication Established, 19th is "On")<br></div><div><br></div><div>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.</div><div>I've included tcpdump logs as well as the description of OID I've found.</div><div><br></div><div>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?</div><div>I am running NUT 2.8.0 at the moment.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">czw., 9 mar 2023 o 14:14 mateuszx <<a href="mailto:jasmati09@gmail.com" target="_blank">jasmati09@gmail.com</a>> napisał(a):<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>I've got an update on this case</div><div>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</div><div>.iso.org.dod.internet.private.enterprises.apc.products.hardware.ups.upsState.upsBasicState.upsBasicStateOutputState.0 = 0001010000000000001000000000000000000000000000000000000000000000</div><div>(mib used for this snmpget was powernet441.mib)</div><div>(I got a description about each bit here, 4th bit is for OnLine, 6th stands for Serial Communication Established, 19th is "On")<br></div><div><br></div><div>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.</div><div>I've included tcpdump logs as well as the description of OID I've found.</div><div><br></div><div>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?</div><div>I am running NUT 2.8.0 at the moment.</div><div><br></div><div>Matthew<br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">czw., 2 mar 2023 o 10:46 mateuszx <<a href="mailto:jasmati09@gmail.com" target="_blank">jasmati09@gmail.com</a>> napisał(a):<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>NUT version is 2.7.4-14ubuntu2 indeed.</div><div>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.</div><div>Anyway thanks for the output, I really appreciate it</div><div><br></div><div>Matthew<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">wt., 28 lut 2023 o 13:29 Jim Klimov via Nut-upsdev <<a href="mailto:nut-upsdev@alioth-lists.debian.net" target="_blank">nut-upsdev@alioth-lists.debian.net</a>> napisał(a):<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto">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)...<div dir="auto"><br></div><div dir="auto">Many distros still ship 2.7.4...</div><div dir="auto"><br></div><div dir="auto">Jim</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Feb 28, 2023, 00:57 Greg Troxel <<a href="mailto:gdt@lexort.com" target="_blank">gdt@lexort.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">mateuszx via Nut-upsdev <<a href="mailto:nut-upsdev@alioth-lists.debian.net" rel="noreferrer" target="_blank">nut-upsdev@alioth-lists.debian.net</a>> writes:<br>
<br>
> At my workplace I have exact UPS config as stated in the subject (APC MGE<br>
> Galaxy 5500 + AP9635CH).<br>
> I have it set up to work with snmp-ups NUT driver.<br>
> Despite many readings from *upsc* command I am not receiving "On Line<br>
> Status" (ups.status OL) nor "On Battery Status" (ups.status OB) and<br>
> therefore I can't get my systems to shutdown during a power outage event.<br>
> (device and ups) Serial Number seems to be missing too in both *upsc *AND Web<br>
> Interface of Network Management Card.<br>
> It can read battery charge just fine (it can even trigger Low Battery<br>
> Status!).<br>
> When I unplug the UPS from line power it does indeed log this event on the<br>
> Web Interface.<br>
<br>
I would run tcpdump and record and examine the SNMP traffic, and turn on<br>
debugging in the driver. It is likely that the SNMP queries for status<br>
are not doing what the driver author expected. You'll have to find out<br>
if your UPS has different variables. snmpwalk may also be useful, or<br>
docs.<br>
<br>
_______________________________________________<br>
Nut-upsdev mailing list<br>
<a href="mailto:Nut-upsdev@alioth-lists.debian.net" rel="noreferrer" target="_blank">Nut-upsdev@alioth-lists.debian.net</a><br>
<a href="https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev" rel="noreferrer noreferrer" target="_blank">https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev</a><br>
</blockquote></div>
_______________________________________________<br>
Nut-upsdev mailing list<br>
<a href="mailto:Nut-upsdev@alioth-lists.debian.net" target="_blank">Nut-upsdev@alioth-lists.debian.net</a><br>
<a href="https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev" rel="noreferrer" target="_blank">https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev</a><br>
</blockquote></div>
</blockquote></div>
</blockquote></div>
</blockquote></div>
</blockquote></div>
</blockquote></div>
</blockquote></div>