similar to: MGE MIB related bug

I think this trunk-to-branch interior merge should be clean, but the merge logic correctly identifies some missing files in the reposurgeon output (checked in -pre7 and -pre4). They are in SVN on that branch, though (ignoring .gitignore for the time being). I only see one java file in scripts/java/jNut/src/main/java/org/networkupstools/jnut/ from reposurgeon.

Citeren Marco Chiappero <marco op absence.it>: > I managed to get twice connected at the same time from the same > machine to a single UPS using different hostnames, so it's > definitely not an IP based check (at least here with 66102 / EC). Never mind. The alarm messages are not bound to a specific outlet, but are sent to all NSM clients that are connected. Which means

Hi all, some time ago I bought at discount price a NMC for managing a few computers using the programmable outlets features available on my MGE Evolution, unuseful otherwise (ATM). However, expecially for my server machine, I don't like very much the NSM client provided by MGE/Eaton and I'd rather use only NUT from my distribution. So, looking at the netxml-ups driver, I started adding

Hello, 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.

Dear Arjen, Arnaud et al, I've just organized an MGE UPS with Ref. 66074 SNMP/Web Transverse Card for testing purposes. Months ago I found a quite simple bug in the UPS-MIB implementation of this card and Schneider Electric guys seemed not to have intention and/or knowledge to fix it. Now local representative sent me an MGE "Pulsar Extreme 2000 VA" model in order to find an

Please report it to NUT developers, with an 'upsc' output for your device. Going back to the classic MIB detection method. Driver exited abnormally Network UPS Tools - Generic SNMP UPS driver 0.70 (2.7.1) kill: No such process No matching MIB found for sysOID '.1.3.6.1.4.1.674.10902.2'! Please report it to NUT developers, with an 'upsc' output for your device. Going back to

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

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

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

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

Dear users, This mail is to announce the beta availability of the mge-xml driver in NUT's trunk. This (overdue) driver allows to support MGE* (UPS Systems and Office Protection Systems) Network Management Cards. This development is sponsored by MGE Office Protection Systems, which is also the NUT sponsor, web hoster and (new) benefactor in general. This driver offers similar services to the

Hello, 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.

Hi, Looking at some udp stuff on snv_57, and I noticed that mib:::udpInDatagrams no longer exists, has this been superceded by mib:::udpHCInDatagrams? From my understanding they represent the same counter, but I''m asking in case this is a bug. I noticed that there is still a reference to udpInDatagrams in the DTrace testsuite. - Fintan

On October 31, 2017 2:32:36 AM GMT+01:00, Ben Kamen <ben at benkamen.net> wrote: >Hey all, > > >?I'm feeling spunky... and want to update nut to handle the new v2.0 >MIB from CyberPower. > >I've looked at the cyberpower v0.1 .c/.h and being new to working on >nut to this level -- anything anyone has to offer on adding code >besides the obvious? >

On November 2, 2017 5:31:42 AM GMT+01:00, Ben Kamen <ben at benkamen.net> wrote: >On 10/31/2017 01:13 AM, Jim Klimov wrote: >> If the new data is in a separate OID tree, it can quite be a new MIB. >Otherwise you can use the UNIQUE flag and set the preferred (e.g. >newer, more precise) source for a value first in the list of same-named >mappings in existing file - if

On 11/02/2017 01:52 AM, Jim Klimov wrote: > > I believe the main reason for a new set of .c/.h files here would be if the new MIB is defined in a separate subtree. The top-level mapping binds the vendor entry OIDs (often "hidden" so one has to know where to poke). It may also be higher in the list of snmp-ups.h, in case the device also serves the older MIB but you'd prefer the

Chugging along... Question for the gang -- CyberPower lists other items in their MIB for controlling PD units and some other things. Does NUT support all that and should I make an effort to get all that in or should we skip for now and get UPS primary ingredients inserted and tested? just wondering, ?-Ben -- Ben Kamen - O.D.T., S.P.

Hey all, ?I'm feeling spunky... and want to update nut to handle the new v2.0 MIB from CyberPower. I've looked at the cyberpower v0.1 .c/.h and being new to working on nut to this level -- anything anyone has to offer on adding code besides the obvious? like: should the 0.1 and 2.0 coexist somehow? (maybe different files) (also, is there a list of all the parms I can match up from the

On 10/31/2017 01:13 AM, Jim Klimov wrote: > If the new data is in a separate OID tree, it can quite be a new MIB. Otherwise you can use the UNIQUE flag and set the preferred (e.g. newer, more precise) source for a value first in the list of same-named mappings in existing file - if there's a hit on an actual device, it will be used and not iterated onwards. The flag is not yet supported for

Hello. ?I am hoping someone will be willing to help me understand something about hazard plots created with muhaz(...). ?I have some background in statistics (minor in grad school), but I haven't been able to figure one thing about hazard plots. ?I am using hazard plots to track customer cancellations. ?I figure I can treat a cancellation as a "death", and if someone is still a