[Nut-upsdev] Megatec driver status [was: Re: UPS (Megatec) with strange voltage values]

[Alexander I. Gordeev]

Hi, Arnaud, Carlos!

On Wednesday 22 October 2008 12:56:42 you wrote:
> Hi Carlos,
>
> 2008/10/20 Carlos Rodrigues <cefrodrigues at gmail.com>:
> > Now, I think I should take the opportunity to ask if any of the people
> > reading this list is willing to help test the megatec driver, or even
> > take maintainership of it.
> >
> > For a while now I've been using a virtual machine to test changes to
> > the driver, but now I don't have a machine with a serial port anymore,
> > so I'm unable to test with real hardware (even from inside a VM). I
> > could, of course, buy myself a usb-to-serial converter, but must say
> > I've been lacking time as of late so, after ~5 years maintaining this
> > driver (~3 years inside NUT mainline, thanks guys) I guess it's time
> > to pass it on to someone else.
> >
> > The megatec driver is pretty much a done deal, all the new stuff
> > should happen in the megatec_usb driver (for which I'm not the
> > maintainer). I guess whomever picks up official maintainership of this
> > driver could also pick up megatec proper. It makes sense, for me at
> > least.
> >
> > There are still some small things pending in megatec however, that I
> > can do myself provided someone helps testing with real hardware:
> >
> > 1) Adding another parameter to set the pace for serial communications
> > (see the thread mentioned in the subject);
> > 2) Mark the Battvolts_t structure as deprecated/legacy and add the
> > battvolts values for the UPSes listed in the comments to the
> > compatibility list (I don't think this structure should be changed
> > going forward, it is only useful for a small number of users, totaly
> > useless for the majority of users, and confusing for the rest);
> > 3) Adding some more models to the compatibility list (I have one or
> > two pending).
> >
> > So, nothing special. I'll drop a patch to the list instead of
> > commiting immediately, since I don't like commiting untested stuff
> > (even if they look simple at a glance).
> >
> > Any comments?
>
> first, thanks for taking the time to clarify the situation.
> and also for all your hard work during all these years. I recall that
> the initial megatec creation was something hard, and I had to bother
> you a lot on this. But the results are there, and it has greatly
> simplified the drivers list.
>
> @Alex and Jon: what do you think about Carlos proposition?

First, kudos Carlos! You've done a great work. Having a man like you working 
on and testing the megatec protocol layer is really very important for me (at 
least). I'm afraid I cannot do the same job at the moment because I'll have 
much the same problem with testing. The intent of megatec_usb is to support 
crappy low-priced UPSes with crappy unstandard interfaces while AFAIK megatec 
driver supports much superior UPSes as well. I think, my UPS is too dumb to 
be used for megatec driver testing. I have a big problem with testing already 
as a de-facto maintainer of megatec_usb because I have only one UPS which is 
supported by 'krauler' subdriver while the majority of users have UPSes 
supported by 'agiler'-kind subdrivers. I can help them in trivial issues and 
that's all.

So, my word is: I don't want to take megatec maintainership from Carlos until 
I have at least one 'agiler' device (since they tend to better support all 
the features of megatec protocol) or true serial 'megatec' device (I like 
this case more). Currently I have no plans about buying them but things may 
change. It'd be very cool also if somebody takes maintainership 
over 'agiler'-kind subdriver family.
By the way, do you know any UPSes which talk megatec protocol, support all the 
cool features of NUT like load.off, restoring load when the power is back 
(after some time, ideally, to have batteries charged a little) while being 
not very expensive. I pretty much miss these features in my UPS.

--
  Alexander