[Nut-upsdev] Re: RE nut 2.0 fentonups and Xanto S3000R

[Henning Brauer]

* Carlos Rodrigues <carlos.efr at mail.telepac.pt> [2006-04-30 18:59]:
> On 4/29/06, Henning Brauer <henning at openbsd.org> wrote:
> >since that'll happen who-knows-when I have put these changes in the
> >openbsd port in the meantime.
> >
> >for the record, and the magic new megatec driver:
> >-the online-usv.de UPSes have no way to identify themselves
> >-they do not respond to "I"
> >-thus you need a way to force a model.
> That's not a problem for the "megatec" driver. My own UPS doesn't
> identify itself either.

excellent :)

> >the data for the S3000R is in the patch, I refrained from buying more
> >UPSes from them after I saw this divergence in the protocol (well, and
> >other stuff). maintaing an inhouse version of the fentonups driver for
> >3 or 4 years (hmm, maybe we even bought these in 2001... anyway) was
> >painful enough, so please include this in future versions.
> The patch looks like it is only modifying fentonups to accept that
> model, without making any other changes (to correct calculations,
> etc). Am I wrong?

no, there was no need to. just adding the data was goo enough, plus the 
ability to force a model.

> Then megatec (and powermust on the stable branch, for that matter)
> should aready drive that UPS. If it doesn't - check if battery.charge
> ever reaches 100% -, care to send me the output from "upsc"? (It can
> be the output just using powermust, it doesn't need to be megatec).

well, it is running 2.0.0 and the fentonups driver with my changes.

<brahe at paploo>  $ upsc UPS-3 at localhost
battery.charge: 100.0
battery.voltage: 2.26
driver.name: fentonups
driver.parameter.model: XS3000R
driver.parameter.port: /dev/ttym1
driver.version: 2.0.0
driver.version.internal: 1.21
input.frequency: 49.9
input.transfer.high: 275
input.transfer.low: 165
input.voltage: 230.0
output.voltage: 230.0
ups.load: 053
ups.mfr: Online
ups.model: Xanto S3000R
ups.status: OL
ups.temperature: 27.0