[Nut-upsdev] bestfortress driver establishes/loses/establishes communication and so on...

[Oliver Kluge]

[As posted as Ubuntu Question #184284 on Launchpad]

Hi, I try to set up nut (2.4.3) on my Lucid (10.04.3 LTS) to make use of 
my old but very trusty UPS (Best Power Fortress 660 LI).

Yes, this UPS is old (about 16 years), but with its third battery pack 
last week it is as good as new. It runs perfectly well with Windows XP, 
Vista and even Windows 7. But not so with Ubuntu and nut.

After several hurdles I managed to get nut start flawlessly (although I 
always have to do upsdrvctl start und /etc/init.d/nut start manually, 
but that is just another [reported] bug, upstart doesn't start some 
daemons). Btw., the last hurdle was that nutmon did not want to start 
without its own user, nutmon, which was not setup by the package.

The problem is that soon after nut started successfully, communication 
to the UPS is lost, with "data stale". After some minutes, communication 
gets re-established. Then lost again and so on and on and on...

When communication is reported established, upsc fortress gives me a 
comple list of values that tell me that upsmon really talked to the 
device (although high and low transition are always missing?).

As this is nut 2, fortress-drivers are set back to being experimental, I 
know, but I do have a Fortress so I have to use these drivers (0.02 - 
2.4.3). The Fortress is set to use advanced communication mode 4, which 
means "real" cable 95B and 9600 bits per second on /dev/ttyS0. I have 
told the driver so (adding baudrate=9600 to /etc/nut/ups.conf) and the 
fact that sometimes comm is established tells me its not a speed issue.

It also isn't a load issue - this is an Intel Quadcore machine, 9600 bps 
of serial communication should not be an issue. I did experiment with 
pollintervall, maxage, pollfreq and so on - doesn change anything, only 
the amount of time between the glitches. The windows app (Checkups II) 
polls the UPS even more often, seemingly once per second, so 
communication "overload" on the UPS part can also be ruled out.

In the meantime I have done some debugging with even higher debug levels 
(up to 6 seem to be supported). With -DDDD it seems like the driver does 
not poll in the intervall specified. After communication is established, 
and all data from within the UPS are present in the debug output, the 
USV data is immediately marked stale. One would tend to believe that 
after a successful poll of UPS data the stale declaration could only 
come after one intervall has elapsed, but it comes at once. After that 
there is silence. No more debug output from the driver. Not one single 
line of debug output.

But the driver isn't dead. It's still running, and occasionally it does 
re-establish communication with the UPS and delivers some data. But no 
debug output...

Thanks for your help.
Oliver