[Nut-upsuser] Riello Dialog Plus UPS

[Massimiliano Giorgi]

Arjen de Korte wrote:
>> I have discovered that if you build a custom cable you can use the
>> genericups driver (tha cable supplied with the UPS does not work)...
> 
> How is that one wired?
> 

the cable supplied with the UPS is a normal modem (DTE-DCE, DB9 male-DB9
 female, pin-to-pin connected) cable; I have only added the pull-up
resistors (on another cable!)

the only documentation I have found is here
http://www.riello-ups.co.uk/downloads/dialog-plus-tm.pdf

on page 15 it tells about the RS-232 control signal but it does not tell
that the supplied cable does not work! (well... in my system does not work)

perhaps the UPS use the PSGPSER-0103 comunication protocol but I have
not found any informations

>> I have build a "normal" RS232 DTE-DCE cable (I have connected pin 1 with
>> pin 1, pin 2 with pin 2, and so on... using two DB-9 connectors) AND I
>> have used 3 pull-up resistors (I have used 4.7 KOhm) between pin 7 and
>> pin 9 (RTS to RING), pin 7 and pin 8 (RTS to CTS) and between pin 4 and
>> pin 1 (DTR to DCD)...
>> With this cable the following configuration works...
> 
> Which NUT version? Looking at the values below, this probably is the
> version from the trunk, otherwise the override with 'SD=ST' would be
> ineffective.

well... I have made some test on a debian etch (nut 2.0.4) and lenny
(nut 2.2.1)... I have used all the daemons in foreground and with a -DDD
to see what happens...
when genericups start it write

"parse_output_signals: SD overriden with ST"

so I suppose that this setting was in use but (you  are right) probably
is inefective

in the previous email I have forgot to tell that "it seem to function
properly BUT the ups does not go down", the system goes down on a low
battery condition properly but the ups is not killed... so if the main
return the systems connected to the ups does not go up (they have not
seen a AC power lost)...

> 
>> [myups]
>> driver=genericups
>> port=/dev/ttyS0
>> desc="My UPS"
>> upstype=0
>> mfr="Riello Dialog Plus"
>> model="Dialog Plus 2200VA"
>> sdtime=20
>> OL=RNG
>> LB=-CTS
>> SD=ST
>> CP=DTR+RTS
> 
> What exactly did you test here? Have you run 'upsmon -c fsd' both with and
> without mains present? What was the behaviour of the UPS in these cases?

I have tested the OL (this is simple)... I have tested if the system
goes down on LB (but I have not tested if the ups raise CTS on a low
battery condition!)... if the DTR and RTS are not high (the pull-up
resistors do not work) and RNG does not change (if main power change)

this morning I have test the UPS running "upsmon -c fsd"... the system
goes down but the UPS remain online (with and without the main present)..
I have look at the source (the trunk) of genericups.c: in the
upsdrv_shutdown function there is a

tcsendbreak(upsfd, 4901)

why 4901?
(PS: anyway the version of nut I have does not execute this line)

I have written some line of C to send a break to the ups...
using a delay of 4901 has no effect (with and without main);
the man page of tcsendbreak on my system tells that " If duration is not
zero, it sends zero-valued bits for some implementation-defined length
of time."; on my system the duration seems to be the delay in
milliseconds; I have tried 20000... nothing... but with 25000:

with the main present... nothing...
without the main... the UPS has been killed immediatly (well, after a
delay of ~20 seconds after the execution of the tcsendbreak)... if the
main return the UPS go up and power all the output (I does not know what
happens if the main return and the battery is low... I hope the ups wait
until the battery is partially charged prior to power the output)

> 
>> there is another signal (DCD) that comunicate the failure of the UPS and
>> the DSR that go to zero when the cable is not connected...
> 
> We could test for the latter too, to get some rudimentary UPS connected,
> so this is an interesting concept.
> 
>> someone can add a new upstype to the next releas of nut?
> 
> Not so fast. It clearly doesn't match any of the existing types, but we
> need to be sure that it really behaves as expected before adding a
> supported type... :-)
> 
> Best regards, Arjen

I can make other test if tell me what to do...
thanks for the help