similar to: Best Ferrups reporting uptime in minutes, not seconds

I have an old (1997) Best Ferrups (model FE18KVA) that I am trying to monitor for the first time, but all the Best drivers fail to communicate with it. In ups_sync() in bestuferrups.c and bestfcom.c, the "time" command is sent and a one-line response is read. However, on my UPS, that command returns the current time and then prompts for a new time setting. I worked around that by just

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.7.1/drivers/bestfcom.c 2013-07-31

I did the testing you suggested, and it was indeed the whitespace. I added another if clause test to the function and everything seems to work. I have working driver that I will email a patch for this list. My coworker says the model ID is configurable though, so we will try that first, which would negate the need to patch the driver. ________________________________________ From: Charles Lepple

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

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 out on the fc command

Hello, I have a Best Ferrups 3.1KVA and I noticed that the percent battery voltage reported from upsc never gets above 69.9%. I believe there is a mistake in the driver. The battery percentage is calculated based on the High Battery Alarm Setpoint (59.6V) instead of the Ideal Voltage which is about 54V (4 batteries x 13.6V). I examined the source code and found that the variable fc.fullvolts is

If you have a BestPower FerrUPS 2.1kva or similar UPS, and use the bestfcom driver, could you please test the following patch? https://github.com/networkupstools/nut/compare/bestfcom_FE I'd like to merge it in for the next release of NUT, but I have no confirmation as to whether it works, or makes things worse. Thanks, -- Charles Lepple clepple at gmail -------------- next part

On 02/20/2018 06:16 PM, Charles Lepple wrote: > Do you have a pinout for that cable? Unsure, but after recent suggestions, it may be working.? Already had NUT from SlackBuilds.org (SBo) installed, but reinstalled to add the group:user. > I forget if it is the default, but you might need to turn off the hardware and software flow control (minicom: Ctrl-A then letter O, "Serial port

Description: Fix warning: variable set but not used [-Wunused-but-set-variable]. bugs.debian.org/633756. Related drivers were not tested. Last-Update: Sat, 13 Aug 2011 14:04:48 +0300 Index: b/drivers/belkinunv.c =================================================================== --- a/drivers/belkinunv.c 2011-05-31 13:36:49.000000000 +0300 +++ b/drivers/belkinunv.c

On 02/13/2018 03:49 AM, Charles Lepple wrote: > On Feb 12, 2018, at 11:53 PM, David Melik wrote: > > On 01/21/2018 05:53 AM, Charles Lepple wrote: >>> If you hook up a terminal emulator to the comms port (1200 baud, 8/N/1 unless stickers and/or configuration DIP switches indicate otherwise), and type "f" <return>, do you get a status line like one of the

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 should fix a situation

I have an excellent old Best Power FE700VA but am suprised it's unlisted.? I thought Best Power ones were for critical applications, mostly for POSIX-based (Unix, etc.) servers, so I want to run it on 64-bit Slackware GNU/Linux.? I'm wondering why, or if it may be added in the future, or if there are any other options.

Hi, my UPS is a Best Fortress LI1420 with the monitoring master running fedora 7. I have to replace the manufacturer's software "Checkups II" because it's not working with releases after fc4. My choice is the nut package. But it isn't just installing rpm's and configure the parameter files. ? The first hurdle to take was realising the UPS doesn't send a prompt.

I've just started using nut , and one of my UPSes is a Best Ferrups 1.8kva bestfcom seems to be the driver that would support it, but as currently in 2.0.2 it doesn't work on the FE1.8kv. I've done some hacking this afternoon and have it basically working. This is the only Best I have, so if anyone else is working on this, I was hoping to co-ordinate so I don't break any

On Jan 21, 2018, at 1:12 AM, David Melik <dchmelik at gmail.com> wrote: > > I have an excellent old Best Power FE700VA but am suprised it's unlisted. I thought Best Power ones were for critical applications, mostly for POSIX-based (Unix, etc.) servers, so I want to run it on 64-bit Slackware GNU/Linux. I'm wondering why, or if it may be added in the future, or if there are

On 01/21/2018 05:53 AM, Charles Lepple wrote: > My understanding was that many of the older Best Power units were downstream of generators, and as such, full-blown power outages of both mains and generator power were not expected. > > That said, it might be that the "bestfcom" driver predates when we were actively collecting specific model names for the Hardware Compatibility

On Mar 19, 2018, at 4:00 AM, David Melik wrote: > >> Then you can launch the driver with at least one "-D" flag: >> >> /usr/libexec/nut/bestfcom -a ups -D > > I thought there was a lot more to it than that, but after I ran that stuff, the driver outputs. However, /etc/rc.d/rc.ups initialization script might not do anything yet (only the command you gave,

On Dec 25, 2018, at 4:07 AM, David Melik wrote: > > Lately I got (used) an APC Back UPS Pro 1000 and Back UPS NS 1080. I got an [8P8C]-to-USB cable from another UPS, but the Pro isn't detected (with usbhid-ups.) I haven't tried the NS yet but it seems to not be on the list though looks just like the Pro. > There are a few different angles we can approach this one from. What

Lately I got (used) an APC Back UPS Pro 1000 and Back UPS NS 1080. I got an ethernet-to-USB cable from another UPS, but the Pro isn't detected (with usbhid-ups.) I haven't tried the NS yet but it seems to not be on the list though looks just like the Pro. Some months ago I was discussing setup of a Ferrups 700VA.  I got it to work only with a command in rc.local, but not automatically

I finally got around to writing myself a NUT UPS monitoring tool. NUT's UPS monitoring CGI tools provide a detailed instantaneous view of the UPS's state at any moment, but provide no history. The attached tool, upswatch, uses Kiss Gabor's UPS::Nut module and Tobi Oetiker's rrdtool to provide a graphical history of the major UPS operating parameters via a web browser.