Nut upsuser - May 2007 - Trying to fix "Unsupported combination of battery voltage / nr. of batteries" error

Hi, everyone,

I've recently bought a UPS from Mecer. This is a South African brand
that basically resells Mustek hardware, and this UPS is no exception;
it's a Mustek product. It does come with software for Linux, but that
is terrible (the background process that monitors the UPS is written
in Java and needs a terminal to start properly, so you can't run it
from a startup script... that sort of nonsense). So I was very happy
to discover NUT.

However, while NUT does recognize the UPS as using a Mecatec type
protocol and can communicate with it, I get the following error
message:

"This UPS has an unsupported combination of battery voltage/number of
batteries"

The UPS has 3 batteries of 12V each. The nominal voltage is 36V but
the UPS reports 40.8V (which is correct; the float charging voltage is
13.6V per battery). 

This message is generated by the driver (megatec.c) but I'm not sure
what causes it. The comments in the driver code are a bit sparse.

Questions:

- What condition (voltage, other parameters reported by the UPS) cause
this error to occur?

- How can I get debugging info (e.g. the raw data reported by the UPS)
out of the driver or other portions of the code?

- Can I change set_battery_params() in megatec.c with impunity?

Thanks!


Kind regards,
    Frank van Wensveen

---
 * Origin: www.vanwensveen.nl (80.253.112.29)

On 5/1/07, Frank van Wensveen <frankvw@myconnection.co.za>
wrote:
> Hi, everyone,
>
> I've recently bought a UPS from Mecer. This is a South African brand
> that basically resells Mustek hardware, and this UPS is no exception;
> it's a Mustek product. It does come with software for Linux, but that
> is terrible (the background process that monitors the UPS is written
> in Java and needs a terminal to start properly, so you can't run it
> from a startup script... that sort of nonsense). So I was very happy
> to discover NUT.
>
> However, while NUT does recognize the UPS as using a Mecatec type
> protocol and can communicate with it, I get the following error
> message:
>
> "This UPS has an unsupported combination of battery voltage/number of
> batteries"
>
> The UPS has 3 batteries of 12V each. The nominal voltage is 36V but
> the UPS reports 40.8V (which is correct; the float charging voltage is
> 13.6V per battery).
It looks like the existing battery table has some odd per-battery
voltages for other 36V UPSes:

http://boxster.ghz.cc/projects/nut/browser/trunk/drivers/megatec.c#L106
> - How can I get debugging info (e.g. the raw data reported by the UPS)
> out of the driver or other portions of the code?
You can start the megatec driver (or any other driver, for that
matter) with at least one "-D" on the command line to enable debug
output. One "-D" should print the voltages used to determine the
proper charge parameters.
> - Can I change set_battery_params() in megatec.c with impunity?
You might want to see if you can get away with just adding to the
aforementioned table.

(These are just some starting points - Carlos (the driver author) or
others with specific megatec experience can weigh in with more
authoritative information.)

-- 
- Charles Lepple

On 5/1/07, Frank van Wensveen <frankvw@myconnection.co.za>
wrote:
> I had seen a line in the megatec driver that apparently supported 36V
> UPSes. However the values didn't make sense to me. Meanwhile I've
done
> some digging in the code, the protocol description and what the UPS
> has to say about its own parameters, and now they make even less
> sense. :-) If I understand it correctly, the 36V line in the current
> megatec driver code contains values per cell, not for the entire
> battery. Is that correct?
Not really. The driver doesn't know anything about the number of
cells, or their type, because the UPS says nothing about it. The only
think that can be obtained is the nominal voltage (from the "F"
command) and the present voltage (from the "Q1" command). Since the
vendors can put anything in either of these two values (totals, per
cell, etc)... you see where I'm getting at.
> (234.4 233.9 228.0 006 50.1 40.9 25.0 00001000
The UPS is fully charged here?
> #230.0 008 36.00 50.0
[snip]
> I'll need to fully discharge the UPS to obtain that value. However the
> generally recommended discharge cut-off point for sealed lead-acid
> batteries is 1.8V/cell which on a 26V battery comes to 32.4V. That
> doesn't mean of course that the UPS will wait that long until it
> triggers a load shutdown. So I'll run the test one of these days and
> plug in the appropriate value.
That's ok. Like I said, the voltage at which the UPS triggers a low
battery state (which the driver always reports) should be enough.
> In closing, wouldn't it be more elegant and convenient to have these
> battery values table in a separate config file (or section in an
> existing config file) rather than have it hardcoded in the driver?
The values hardcoded in the driver are the known values. However,
there is a parameter to override this in "ups.conf":

  battvolts = discharged:charged

For example:

  battvolts = 30.0:40.9

-- 
Carlos Rodrigues

On 5/1/07, Frank van Wensveen <frankvw@myconnection.co.za>
wrote:
> "This UPS has an unsupported combination of battery voltage/number of
> batteries"
This is not an error, it just means the driver doesn't have the values
for your UPS, and so can't provide battery charge (percentage) values.
> - How can I get debugging info (e.g. the raw data reported by the UPS)
> out of the driver or other portions of the code?
Run "megatec -DDD yourups" and send the output to me.
> - Can I change set_battery_params() in megatec.c with impunity?
No. The values for you UPS should be added to the "batteries" table.
>From the debug output obtained from the command above, I can fill some
of the values necessary. But I will also need you to provide the
battery voltage when the UPS enters "low battery", the battery voltage
reported when the UPS is fully charged and when it is fully discharged
(if you can't get this last value, it should be ok).

-- 
Carlos Rodrigues

Skipped content of type multipart/alternative-------------- next part
--------------
Network UPS Tools - Megatec protocol driver 1.5 (2.0.5)
Carlos Rodrigues (c) 2003-2006

debug level is '3'
Starting UPS detection process...
Attempting to detect the UPS...
Sending "Q1" command...
"Q1" command successful.
Attempting to detect the UPS...
Sending "Q1" command...
"Q1" command successful.
Attempting to detect the UPS...
Sending "Q1" command...
"Q1" command successful.
Attempting to detect the UPS...
Sending "Q1" command...
"Q1" command successful.
Attempting to detect the UPS...
Sending "Q1" command...
"Q1" command successful.
0 out of 5 detection attempts failed (minimum failures: 2).
Asking for UPS information ("I" command)...
UPS information: 228.0 140.0 230.0 034 50.0 2.29 36.5 00000000
Megatec protocol UPS detected [228.0 140.0 230 0 034 50.0 2.29 36.5].
Asking for UPS power ratings ("F" command)...
UPS power ratings: 228.0 140.0 231.0 032 50.0 2.29 36.5 00000000
Asking for UPS status ("Q1" command)...
UPS status: 228.0 140.0 231.0 033 50.0 2.29 36.5 00000000
231.0V battery, interval [1.6V, 2.3V].
Done setting up the UPS.
Asking for UPS status ("Q1" command)...
UPS status: 228.0 140.0 230.0 034 50.0 2.29 36.5 00000000
dstate_init: sock /var/state/ups/megatec-ttyS0 open on fd 5
Asking for UPS status ("Q1" command)...
UPS status: 228.0 140.0 230.0 033 50.0 2.29 36.5 00000000
Asking for UPS status ("Q1" command)...
UPS status: 228.0 140.0 230.0 033 50.0 2.29 36.5 00000000
Asking for UPS status ("Q1" command)...
UPS status: 228.0 140.0 231.0 032 50.0 2.29 36.5 00000000
Asking for UPS status ("Q1" command)...
UPS status: 228.0 140.0 231.0 033 50.0 2.29 36.5 00000000
Asking for UPS status ("Q1" command)...
UPS status: 228.0 140.0 231.0 034 50.0 2.29 36.5 00000000
Asking for UPS status ("Q1" command)...
UPS status: 228.0 140.0 230.0 033 50.0 2.29 36.5 00000000
Asking for UPS status ("Q1" command)...
UPS status: 228.0 140.0 230.0 033 50.0 2.29 36.5 00000000
Asking for UPS status ("Q1" command)...
UPS status: 228.0 140.0 230.0 033 50.1 2.29 36.5 00000000
Asking for UPS status ("Q1" command)...
UPS status: 228.0 140.0 230.0 035 50.1 2.29 36.5 00000000
Asking for UPS status ("Q1" command)...
UPS status: 228.0 140.0 230.0 034 50.1 2.29 36.5 00000000
Asking for UPS status ("Q1" command)...
UPS status: 228.0 140.0 231.0 034 50.1 2.29 36.5 00000000
Asking for UPS status ("Q1" command)...
UPS status: 228.0 140.0 230.0 033 50.1 2.29 36.5 00000000
Asking for UPS status ("Q1" command)...
UPS status: 228.0 140.0 230.0 033 50.1 2.29 36.5 00000000
Asking for UPS status ("Q1" command)...
UPS status: 228.0 140.0 230.0 033 50.1 2.29 36.5 00000000
Asking for UPS status ("Q1" command)...
UPS status: 228.0 140.0 230.0 033 50.1 2.29 36.5 00000000
Asking for UPS status ("Q1" command)...
UPS status: 228.0 140.0 230.0 033 50.1 2.29 36.5 00000000
Asking for UPS status ("Q1" command)...
UPS status: 228.0 140.0 231.0 033 50.1 2.29 36.5 00000000
Asking for UPS status ("Q1" command)...
UPS status: 228.0 140.0 231.0 034 50.1 2.29 36.5 00000000
Asking for UPS status ("Q1" command)...
UPS status: 228.0 140.0 230.0 033 50.1 2.29 36.5 00000000
Asking for UPS status ("Q1" command)...
UPS status: 228.0 140.0 231.0 033 50.1 2.29 36.5 00000000
Asking for UPS status ("Q1" command)...
UPS status: 228.0 140.0 231.0 032 50.1 2.29 36.5 00000000
Asking for UPS status ("Q1" command)...
UPS status: 228.0 140.0 230.0 033 50.1 2.29 36.5 00000000
Asking for UPS status ("Q1" command)...
UPS status: 228.0 140.0 230.0 033 50.1 2.29 36.5 00000000
Asking for UPS status ("Q1" command)...
UPS status: 228.0 140.0 231.0 034 50.1 2.29 36.5 00000000
Asking for UPS status ("Q1" command)...
UPS status: 228.0 140.0 230.0 033 50.1 2.29 36.5 00000000
Asking for UPS status ("Q1" command)...
UPS status: 228.0 140.0 230.0 035 50.1 2.29 36.5 00000000
Asking for UPS status ("Q1" command)...
UPS status: 228.0 140.0 230.0 033 50.1 2.29 36.5 00000000

> I also found a problem in serial.c I am not sure if it is intentional
> however the buffer size being read from the serial port was 64 chars.
This is intentional.
> That block was then scanned through to find the end of line char and once
> it was found the remaining data in that block was discarded.
>
> The side effect was that it could take some time before there was a valid
> block of data to be read in that the driver could handle. Anyway, I
> modified
> the block size to 1 char and I got a lot more accurate data appearing.
This is something that should be fixed in the driver. Apparently, the
serial in- and output buffers need to be flushed before sending a command
and reading back the reply.

Best regards, Arjen
-- 
Eindhoven - The Netherlands
Key fingerprint - 66 4E 03 2C 9D B5 CB 9B  7A FE 7E C1 EE 88 BC 57

On 5/3/07, Gary van Blerk <gary@cartrack.co.za>
wrote:
> Please tell me where I should use this battvolts option and what the
> parameters should be?
> I haven't seen any reference to it in either the source or
documentation in
> version 2.0.5
Hmmm, you're right. I added that option after 2.0.5... You can either
install the latest development version of NUT, or you can just pick
its "megatec.c" and "megatec.h" files and drop them over the
ones in
2.0.5, it should work.

-- 
Carlos Rodrigues

On 5/3/07, Gary van Blerk <gary@cartrack.co.za>
wrote:
> The megatec.c is stock standard. I have made no changes to it. I have
> noticed the same thing in minicom.
> The ups will respond to Q1 however it does not stop sending output after a
> single Q1. This seems to continue for approximately 3 minutes before
another
> Q1 is required. If you constantly send the Ups the Q1 command, it has no
> effect other than the output continues for as long as you keep sending Q1.
> There is also no visible difference between Q1 and any other command you
> might enter. It seems to ignore those.
What I find strange is the driver not detecting the problems with the
output of those commands (if the ouput isn't exactly a certain number
of characters specified for each command, the driver should complain).
I may have to rework the error detection code... bleh.
> I suspect this UPS was some kind of gross violation of all that is holy.
> At least it seems to work though.
Surprisingly... I'll work on this when I have a bit of time available.
I'll try not to break support for your UPS :)

Meanwhile, if you can send me some kind of log of a minicom session to
the UPS I would appreciate it. Something that shows the "I",
"F" and
"Q1" commands being called in different sequences.

Some things I'm looking for:

   1. what happens if an "I" of "F" command is sent while
the UPS is
pumping output from "Q1";
   2. does sending a "C" command stop the output from "Q1"?
   3. does sending some invalid command (e.g. "B") stop the output
from "Q1"? What's the output for this invalid command?

-- 
Carlos Rodrigues

On 5/3/07, Gary van Blerk <gary@cartrack.co.za>
wrote:
> I actually think the ups is always spewing this data and it does not care
> for any data you send to it. You do not get any errors when you type any
> characters like B, Q1-Q0, qwerty etc. It all seems to be ignored.
Invalid commands produce no error according to the protocol. Invalid
input should just be echoed back.
> Hmm, tried the entire alphabet, upper and lower case, numbers and symbols
> and it still continues to send out the same data.
>
> Guess the ups is a lot more primitive than I originally thought.
If the UPS ignores everything after a Q1 command, then NUT can't drive
that hardware properly. You get the current status and the machines
connected to it can power themselves off ok, but the UPS will still
drain the battery afterwards and the machines won't come back if the
power returns.

-- 
Carlos Rodrigues

On 5/1/07, Frank van Wensveen <frankvw@myconnection.co.za>
wrote:
> { 36, 30.0, 42.0, 32.5, 41.0 }, /* Mecer / Mustek 2kVA
>                                 ME-2000 - Added FvW 1 May 2007 */
To add this to the trunk version of "megatec.c", I need an extra
parameter (the "low battery" voltage).

-- 
Carlos Rodrigues