Hi all
I'm developing a NUT driver for a custom UPS found on ASEM PB 1300 devices
(http://www.asem.it/prodotti/industrial-automation/box-pcs/performance/pb1300/)
It's based on some custom charger and a bq2060 battery monitor, talk to it
on
i2c bus.
I will have something usable in a few days. Got some questions/considerations,
though:
*) interested in integrating into NUT?
*) would you prefer a pull request on github or a patch here?
*) I would patch configure to add a --with-i2c option
*) Linux only, on Windows there's vendor provided software.
--
Giuseppe Corbelli
WASP Software Engineer, Copan Italia S.p.A
Phone: +390303666318 Fax: +390302659932
E-mail: giuseppe.corbelli at copanitalia.com
On May 28, 2014, at 3:01 AM, Giuseppe Corbelli wrote:> Hi all > I'm developing a NUT driver for a custom UPS found on ASEM PB 1300 devices > (http://www.asem.it/prodotti/industrial-automation/box-pcs/performance/pb1300/) > > It's based on some custom charger and a bq2060 battery monitor, talk to it on i2c bus.Looks interesting!> I will have something usable in a few days. Got some questions/considerations, though: > *) interested in integrating into NUT?Yes, we're happy to help integrate. For less common devices, we might ask for some testing assistance later if there is a change to the way drivers operate, but once you submit the driver, we will try to keep things building properly.> *) would you prefer a pull request on github or a patch here?Either way works for us. The Github pull requests and issues are better for things that we might not get to immediately, but when adding a new driver, there is usually a lot of discussion on either the pull request or the mailing lists. It's up to you.> *) I would patch configure to add a --with-i2c optionAre you using an I2C library? If so, it might be good to use the name of that library in the flag. Originally, our --with-ssl flag implied OpenSSL, but several years ago we started adding NSS support as well, and the flags got complicated. If it is a Linux-specific i2c implementation, something like --with-linux-i2c might be better.> *) Linux only, on Windows there's vendor provided software.Not a problem, although if it does not support *BSD, we should document that as well. At the moment, nobody has stepped up to do anything other than minor maintenance on the Windows port of NUT, so I don't think that will be a problem. -- Charles Lepple clepple at gmail
On 28/05/2014 14:20, Charles Lepple wrote:> On May 28, 2014, at 3:01 AM, Giuseppe Corbelli wrote: > >> Hi all >> I'm developing a NUT driver for a custom UPS found on ASEM PB 1300 devices >> (http://www.asem.it/prodotti/industrial-automation/box-pcs/performance/pb1300/) >> >> It's based on some custom charger and a bq2060 battery monitor, talk to it on i2c bus. > > Looks interesting! > >> I will have something usable in a few days. Got some questions/considerations, though: >> *) interested in integrating into NUT? > > Yes, we're happy to help integrate. For less common devices, we might ask > for some testing assistance later if there is a change to the way drivers > operate, but once you submit the driver, we will try to keep things building > properly.No problem. I should have access to the same hardware in the future.>> *) would you prefer a pull request on github or a patch here? > > Either way works for us. The Github pull requests and issues are better > for things that we might not get to immediately, but when adding a new driver, > there is usually a lot of discussion on either the pull request or the mailing > lists. It's up to you.Mailing list.>> *) I would patch configure to add a --with-i2c option > > Are you using an I2C library? If so, it might be good to use the name of > that library in the flag. Originally, our --with-ssl flag implied OpenSSL, but > several years ago we started adding NSS support as well, and the flags got > complicated.No library. The linux/i2c-dev.h include defines some inlined functions that basically wrap an ioctl(fd, I2C_SMBUS, params) call.> If it is a Linux-specific i2c implementation, something like --with-linux-i2c might be better.Sounds good.>> *) Linux only, on Windows there's vendor provided software. > > Not a problem, although if it does not support *BSD, we should document > that as well. At the moment, nobody has stepped up to do anything other than minor > maintenance on the Windows port of NUT, so I don't think that will be a problem.On *BSD the i2c interface will likely be different, and I don't use *BSD at work, so the driver will not support it. -- Giuseppe Corbelli WASP Software Engineer, Copan Italia S.p.A Phone: +390303666318 Fax: +390302659932 E-mail: giuseppe.corbelli at copanitalia.com