similar to: Best Power FE700VA?

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 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

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 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 following? >> >>

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

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

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

    Lately I replaced my 10+-year-old server with a nano-ITX-type one that has USB but not old serial ports.  I connected my FE700VA to DB25-to-9-to-USB cables, but haven't been able to set it up. Apparently my DB9-to-USB cable (Prolific Technology, Inc. PL2303 Serial Port) has issues needing old software (setserial?) and some new software (fconfigure) being changed.  Has anyone managed

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

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

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

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 Feb 19, 2018, at 3:44 PM, David Melik wrote: > > Minicom listed a blank modem init string, and 'f' did nothing. Do you have a pinout for that cable? 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 setup"). I would also recommend double-checking the serial port name

I had a power hiccup yesterday and a server connected to a Best Ferrups 18KVA shutdown. The problem is that the UPS is reporting remaining runtime in minutes but nut treats it as seconds (so nut thought it only had 46 seconds left). Simple patch: diff -urN nut-2.2.1-dist/drivers/bestfcom.c nut-2.2.1/drivers/bestfcom.c --- nut-2.2.1-dist/drivers/bestfcom.c 2008-06-13 14:04:07.000000000 -0500

On 03/21/2018 07:07 PM, Charles Lepple wrote: > On Mar 20, 2018, at 6:06 PM, David Melik wrote: >> Ok, around 24hrs ago I retested, but the (same) output is still on >> the screen without it going into background to release tty/sh... > My mistake - I misinterpreted the log you posted. Without the "-D" flag, the driver should go into the background in a matter of

On 03/19/2018 04:49 AM, Charles Lepple wrote: > The rc-style init systems typically want programs like the drivers to > go into the background on their own (as the driver does without "-D", > or when launched by "upsdrvctl start"). Other init systems like > launchd or systemd will monitor the PID of the program to restart it > if necessary, so they work best

On Mar 20, 2018, at 6:06 PM, David Melik wrote: > > On 03/19/2018 04:49 AM, Charles Lepple wrote: >> The rc-style init systems typically want programs like the drivers to go into the background on their own (as the driver does without "-D", or when launched by "upsdrvctl start"). Other init systems like launchd or systemd will monitor the PID of the program to

On Mar 22, 2018, at 10:22 PM, David Melik <dchmelik at gmail.com> wrote: > > I assume if I just go through the setup instructions on the NUT website, that'll make the server automatically load this driver on boot. If the Slackware startup scripts call "upsdrvctl start", and the UPS is listed in ups.conf, that should start the driver at boot.

On 03/22/2018 07:43 PM, Charles Lepple wrote: > If the Slackware startup scripts call "upsdrvctl start", and the UPS > is listed in ups.conf, that should start the driver at boot. Now I see that also after doing necessary things in http://networkupstools.org/docs/user-manual.chunked/index.html chapters five and six (only difference was package I'm using doesn't use

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