Hi,
I just acquired a Ritmo AS-800VA.
Unfortunately, it doesn't work out of the box with nut - so I had to do a
bit of reverse engineering on the protocol to get it working. Am now
posting my findings here in the hope it will get this added to the next
release.
There are also 1000VA and 12000VA versions that this should work with.
The protocol is very similar to the megatec protocol - although simpler.
Like megatec - it responds to a 'Q1' request.
The response is slightly different - instead of the megatec 46 character
reply string - the ritmo unit replies with a 35 character string of the
form:
(AAA BBB CCC DD.D EE.E FFF GGGGGGGG
Where:
AAA is input voltage
BBB is output voltage
CCC is load - not sure what the range is - when my server plugged in and
running - this is 4
DD.D is input frequency
EE.E is output frequency
FFF is battery voltage - seems to be 195 when fully charged - about 160
when flat.
GGGGGGGG is a bit mask of the form b7b6b5b4b3b2b1b0. So far I've only
established b7=1 when on battery power, b6=1 when battery level is
critical. Have not seen the remaining bits change from 0.
A sample response to the "Q1" request when my server is running
normally is:
(233 233 004 50.0 50.0 195 00000000
The unit does not respond to any of the other megatec queries.
I have modified megatec.c with changes to support this - and attached it
to this email.
I don't think I broke anything megatec related - but it would be prudent
if someone tested it to make sure.
Have been running it on my server for the last week or so with no probs -
so the ritmo code is ok.
Other notes:
1) The unit requires rts to be set high, and is also slower than the
megatec units, so my corresponding ups.conf entry is:
[Ritmo800]
driver = megatec
port = /dev/ttyS0
sendpace = 300
dtr = 1
rts = 1
battvolts=160:195
2) The critically low battery flag turns on quite late - so there isn't
really enough time to switch off a pc when this turns on - however the
battery itself lasts as long as you would expect from any other 800VA UPS.
Let me know if you have questions.
Thanks,
-Gino
-------------- next part --------------
A non-text attachment was scrubbed...
Name: megatec.c
Type: text/x-csrc
Size: 29845 bytes
Desc: not available
URL:
<http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20091027/82032873/attachment-0001.c>
On Oct 26, 2009, at 9:44 PM, "Gino Putrino" <ginoputrino at ginoputrino.dyndns.org > wrote:> Hi, > I just acquired a Ritmo AS-800VA. > Unfortunately, it doesn't work out of the box with nut - so I had to > do a > bit of reverse engineering on the protocol to get it working. Am now > posting my findings here in the hope it will get this added to the > next > release. > > There are also 1000VA and 12000VA versions that this should work with. > > The protocol is very similar to the megatec protocol - although > simpler. > Like megatec - it responds to a 'Q1' request. > The response is slightly different - instead of the megatec 46 > character > reply string - the ritmo unit replies with a 35 character string of > the > form: > > (AAA BBB CCC DD.D EE.E FFF GGGGGGGG > > Where: > AAA is input voltage > BBB is output voltage > CCC is load - not sure what the range is - when my server plugged > in and > running - this is 4 > DD.D is input frequency > EE.E is output frequency > FFF is battery voltage - seems to be 195 when fully charged - > about 160 > when flat. > GGGGGGGG is a bit mask of the form b7b6b5b4b3b2b1b0. So far I've > only > established b7=1 when on battery power, b6=1 when battery level is > critical. Have not seen the remaining bits change from 0. > > A sample response to the "Q1" request when my server is running > normally is: > (233 233 004 50.0 50.0 195 00000000 > > The unit does not respond to any of the other megatec queries. >Including the "I" query? (For identifying the vendor and model) Also, it is easier for us to analyze proposed code patches if they are sent in the form of a unified diff ("diff -u file.old.c file.c"). This is especially true if the driver in question has had changes since the last release.