search for: bestpow

The problem will only affect newer firmwares on the BestPower FerrUPS 2.1kva units. Additional white-space was the issue. I added a if clause to the bestfcom driver to account for this without breaking what was there. Here is the patch: diff -rupN release-orig/nut-2.7.1/drivers/bestfcom.c release-patched/nut-2.7.1/drivers/bestfcom.c --- release-orig/nut-2....

...hough, so we will try that first, which would negate the need to patch the driver. ________________________________________ From: Charles Lepple [clepple at gmail.com] Sent: Friday, February 07, 2014 8:21 PM To: Ritter, Nicholas Cc: nut-upsuser at lists.alioth.debian.org Subject: Re: [Nut-upsuser] BestPower Ferrups driver glitch with f commands On Feb 7, 2014, at 3:44 PM, Ritter, Nicholas wrote: > Greetings to you all, > > We are attempting to use NUT to interface with a BestPower FerrUPS FE2.1KVA. We are using the bestfcom driver because the driver listed our UPS as supported. The driver...

I did a bunch of work on this today. It should be all set to go. This patch is to add support for the Cyberpower RMCARD snmp cards. I basically copied the driver for bestpower, changed the name and updated the mib map. I have this running on two separate systems (two separate ups's) and it looks good. The only thing I could not figure out was updating the Makefile.am (my aclocal/libtools seem to be broken.) So I manually updated the Makefile.in to get it compiled....

On Feb 7, 2014, at 3:44 PM, Ritter, Nicholas wrote: > Greetings to you all, > > We are attempting to use NUT to interface with a BestPower FerrUPS FE2.1KVA. We are using the bestfcom driver because the driver listed our UPS as supported. The driver fails, however, because "fc" commands do not exist on the unit. There is a upsdrv_init_nofc() function, but it seems to be brittle in its string matching. > We are running...

Greetings to you all, We are attempting to use NUT to interface with a BestPower FerrUPS FE2.1KVA. We are using the bestfcom driver because the driver listed our UPS as supported. The driver fails, however, because "fc" commands do not exist on the unit. We are running NUT v2.7.1 on CentOS 6.5 with the bestfcom driver. We setup a serial tap and see the UPS error ou...

...about to push the freshly built files to 'networkupstools.github.io' repo, but came across a file Arno added to the repo while publishing 2.7.4 (67a4c0e), but that we lack in 'nut-website' repo: https://github.com/networkupstools/networkupstools.github.io/blob/master/protocols/snmp/BESTPOWER-MIB.mib It's not listed in 'ups-protocols.txt', either, but it seems to be the real match for 'bestpower-mib.c' (see how '.1.3.6.1.4.1.2947.1.1.8.0' is mapped to 'manufacturing date', while http://powerquality.eaton.com/Support/Software-Drivers/Downloads/connec...

...as on 240V EU on 220V) they settled for 230V nominal but then defined tolerences of +/-10% so that everyone suddenly "conformed" to the new regulations without doing anything. Whilst a lot of the UK is actually on 230V now my current house is still on 240V. Looked very strange on my main BestPower and Riello UPS RRD graphs as they show the +10V step change in measured voltage. Having said all that the BestPower delivers 240V and the Riello 230V (adjustable). The Tripp Lite says 240V on the box and is delivering that as its ONLINE nominal output (but drops to <200V on battery power give...

...id: comparing .1.3.6.1.4.1.476.1.42 with .1.3.6.1.4.1.13742 0.018718 match_sysoid: checking MIB baytech 0.018727 match_sysoid: checking MIB cpqpower 0.018737 match_sysoid: comparing .1.3.6.1.4.1.476.1.42 with .1.3.6.1.4.1.232.165.3 0.018746 match_sysoid: checking MIB bestpower 0.018755 match_sysoid: checking MIB cyberpower 0.018764 match_sysoid: comparing .1.3.6.1.4.1.476.1.42 with .1.3.6.1.4.1.3808 0.018773 match_sysoid: checking MIB delta_ups 0.018783 match_sysoid: comparing .1.3.6.1.4.1.476.1.42 with .1.3.6.1.4.1.2254.2.4 0.018792...

To deal with small model string differences that are present on the BestPower FerrUPS 2.1Kva ups, I have the patch below. The change in formatting seams to exist in firmware 9.28 and I think even older firmware. The patch is against the 2.7.1 bestfcom driver. Please pardon any errors in my patch submission has I have only submitted a patch once or twice before. This patch...

...sysoid: comparing .1.3.6.1.4.1.850.1 with .1.3.6.1.4.1.13742 0.027809 match_sysoid: checking MIB baytech 0.027814 match_sysoid: checking MIB cpqpower 0.027820 match_sysoid: comparing .1.3.6.1.4.1.850.1 with .1.3.6.1.4.1.232.165.3 0.027825 match_sysoid: checking MIB bestpower 0.027830 match_sysoid: checking MIB cyberpower 0.027836 match_sysoid: comparing .1.3.6.1.4.1.850.1 with .1.3.6.1.4.1.3808 0.027841 match_sysoid: checking MIB delta_ups 0.027847 match_sysoid: comparing .1.3.6.1.4.1.850.1 with .1.3.6.1.4.1.2254.2.4 0.027853...

...sysoid: comparing .1.3.6.1.4.1.850.1 with .1.3.6.1.4.1.13742 0.028864 match_sysoid: checking MIB baytech 0.028885 match_sysoid: checking MIB cpqpower 0.028907 match_sysoid: comparing .1.3.6.1.4.1.850.1 with .1.3.6.1.4.1.232.165.3 0.028928 match_sysoid: checking MIB bestpower 0.028948 match_sysoid: checking MIB cyberpower 0.028969 match_sysoid: comparing .1.3.6.1.4.1.850.1 with .1.3.6.1.4.1.3808 0.028988 match_sysoid: checking MIB delta_ups 0.029010 match_sysoid: comparing .1.3.6.1.4.1.850.1 with .1.3.6.1.4.1.2254.2.4 0.029030...

...match_sysoid: comparing .1.3.6.1.4.1.318 with .1.3.6.1.4.1.13742 1.119561 match_sysoid: checking MIB baytech 1.119565 match_sysoid: checking MIB cpqpower 1.119570 match_sysoid: comparing .1.3.6.1.4.1.318 with .1.3.6.1.4.1.232.165.3 1.119576 match_sysoid: checking MIB bestpower 1.119580 match_sysoid: checking MIB cyberpower 1.119586 match_sysoid: comparing .1.3.6.1.4.1.318 with .1.3.6.1.4.1.3808 1.119591 match_sysoid: checking MIB ietf 1.119598 match_sysoid: comparing .1.3.6.1.4.1.318 with .1.3.6.1.2.1.33 1.119605 No matching MIB found...

...V) they settled for 230V nominal but then defined tolerences of > +/-10% so that everyone suddenly "conformed" to the new regulations > without doing anything. Whilst a lot of the UK is actually on 230V now > my current house is still on 240V. Looked very strange on my main > BestPower and Riello UPS RRD graphs as they show the +10V step change in > measured voltage. I can change it back to 230V - I was going off of the x2 factor you mentioned. Either way works for me. > Having said all that the BestPower delivers 240V and the Riello 230V > (adjustable). The Tripp Li...

...e.am index bf36319..d8cc127 100644 --- a/drivers/Makefile.am +++ b/drivers/Makefile.am @@ -199,8 +199,7 @@ mge_shut_LDADD = $(LDADD) # SNMP snmp_ups_SOURCES = snmp-ups.c apc-mib.c baytech-mib.c compaq-mib.c eaton-mib.c \ ietf-mib.c mge-mib.c netvision-mib.c powerware-mib.c raritan-pdu-mib.c \ - bestpower-mib.c cyberpower-mib.c delta_ups-mib.c \ - xppc-mib.c + bestpower-mib.c cyberpower-mib.c delta_ups-mib.c xppc-mib.c huawei-mib.c snmp_ups_LDADD = $(LDADD_DRIVERS) $(LIBNETSNMP_LIBS) # NEON XML/HTTP @@ -264,7 +263,7 @@ dist_noinst_HEADERS = apc-mib.h apc-hid.h baytech-mib.h bcmxcp.h \ delta_...

On Sep 25, 2014, at 5:51 PM, Dave Williams <dave at opensourcesolutions.co.uk> wrote: > Using this UPS in the UK on 240V mains. > > Connected via USB: > Bus 001 Device 002: ID 09ae:0001 Tripp Lite > > Requires tripplite_usb driver as it is (Product ID: 0001). There is an > entry in the compatibity list for OMNIVS800 USB (protocol 2012) using > usbhid-ups which is

...t_snmp_get_str() 66.072654 nut_snmp_get(.1.3.6.1.4.1.4779.1.3.5.2.1.24.1) 72.079055 load_mib2nut: trying classic method with 'cpqpower' mib 72.079076 Entering nut_snmp_get_str() 72.079084 nut_snmp_get(.1.3.6.1.4.1.232.165.3.1.1.0) 78.085473 load_mib2nut: trying classic method with 'bestpower' mib 78.085496 Entering nut_snmp_get_str() 78.085504 nut_snmp_get(.1.3.6.1.4.1.2947.1.1.2.0) 84.091922 load_mib2nut: trying classic method with 'cyberpower' mib 84.091945 Entering nut_snmp_get_str() 84.091953 nut_snmp_get(.1.3.6.1.4.1.3808.1.1.1.1.1.1.0) 90.098338 load_mib2nut:...

On Feb 24, 2014, at 6:57 PM, Jason R Begley wrote: > Segmentation fault That's not good. If you crank up the debug level past 2, does it provide any more detail about where it crashed? (We'd only need the last few lines, if they are different.) I don't know how Arch Linux does debug symbols, so the dmesg output doesn't pinpoint which function in libc got bad data. Can you run

> However, this was not an error I was expecting to see when rebuilding: > > http://buildbot.networkupstools.org/public/nut/builders/Debian-website/builds/55/steps/shell/logs/stdio > [...] > Makefile:796: *** target pattern contains no '%'. Stop. > > Any ideas? I think we don't support colons in names of files and dirs: -

Using this UPS in the UK on 240V mains. Connected via USB: Bus 001 Device 002: ID 09ae:0001 Tripp Lite Requires tripplite_usb driver as it is (Product ID: 0001). There is an entry in the compatibity list for OMNIVS800 USB (protocol 2012) using usbhid-ups which is little misleading (although I guess maybe correct for some instances of the UPS). OMNIVS1000 USB (older; product ID: 0001) is

....060256 nut_snmp_get(.1.3.6.1.4.1.232.165.3.1.2.0) 0.060261 nut_snmp_walk(.1.3.6.1.4.1.232.165.3.1.2.0) 0.060266 nut_snmp_walk: max. iteration = 1 0.060274 load_mib2nut: testOID provided and doesn't match MIB 'cpqpower'! 0.060280 load_mib2nut: trying classic method with 'bestpower' mib 0.060285 su_find_info: "ups.model" found 0.060291 Testing ups.model using OID .1.3.6.1.4.1.2947.1.1.2.0 0.060296 Entering nut_snmp_get_str() 0.060301 nut_snmp_get(.1.3.6.1.4.1.2947.1.1.2.0) 0.060306 nut_snmp_walk(.1.3.6.1.4.1.2947.1.1.2.0) 0.060311 nut_snmp_wa...