These are wrong values: battery.temperature: 0.0 device.serial: GXT ups.firmware: ups.mfr.date: 2MR1 ups.serial: GXT
And I don't know what is it: battery.current: 0.00 2010/4/29 Robert Jobbagy <jobbagy.rob...@gmail.com> > Hi guys, > > I tested liebertgxt2/esp2 driver different revisions (rev 2426,2431,2435) > the rev 2432 hasn't big change, the driver name changed. > And I attached the outputs. > I hope these tests help in debug. > > Please Spiros check these files, thanks. > If you need help, write me. > > I looked rev 2435 give wrong output the serial and firmware value are > wrong. > > 2010/4/26 Spiros Ioannou <siv...@gmail.com> > > I've found the bits containing the multipliers, but It may take time to >> find which is which. There are ~15 "multiplier" values hidden in ~70 bits. >> It may be impossible to guess which is which with just 2 sets of outputs >> (from 2 models). >> >> What I can do is get a glimpse on a part of those bit values on driver >> startup and decide for all multipliers with a "switch/case" , having 2 >> cases. That will work for the two models we have data for. If we get another >> model, then we can add more cases. That seems reasonable and easily >> expandable and will avoid deciphering the bits. >> >> -S >> >> >> >> On Sun, Apr 25, 2010 at 9:00 PM, Arjen de Korte >> <nut+de...@de-korte.org<nut%2bde...@de-korte.org> >> > wrote: >> >>> Citeren Robert Jobbagy <jobbagy.rob...@gmail.com>: >>> >>> >>> I think it will be good if the driver check the model of ups (NX or >>>> GXT2) >>>> and >>>> the model is GXT2 then input and output values multipliers will be 0.1 >>>> else >>>> 0.01. >>>> The driver could to use #ifdef preprocess struct. >>>> >>> >>> The latter would require different drivers (since #ifdef statements are >>> processed by the preprocessor, so even before the compiler). Packagers that >>> wish to bundle precompiled binaries would then have to bundle two different >>> drivers. >>> >>> What is your opinion? >>>> >>> >>> Since the differences between the models are so minor, expect me to veto >>> such a change. If there is no way to autodetect this, the driver should >>> default to the settings for the most popular model (usually the smallest) >>> and allow people to override the default setting in 'ups.conf'. If you can't >>> unambiguously determine which multiplier is needed, usually this will cause >>> the least amount of problems. >>> >>> Best regards, Arjen >>> -- >>> Please keep list traffic on the list >>> >>> >>> >>> _______________________________________________ >>> Nut-upsdev mailing list >>> Nut-upsdev@lists.alioth.debian.org >>> http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev >>> >> >> >> _______________________________________________ >> Nut-upsdev mailing list >> Nut-upsdev@lists.alioth.debian.org >> http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev >> > > > > -- > Best Regards, > > Robert > -- Best Regards, Robert
_______________________________________________ Nut-upsdev mailing list Nut-upsdev@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev