Great, thanks! Also just for context, this sounded reminiscent of one of the first NUT drivers, `genericups` (for simple contact-closure support, with IIRC serial-port connections rather than GPIO). Nearby there's also a `generic_modbus" name. Wondering if the new driver should be (similar to) `generic_gpio`. @Community verdict: Then there was also an effort some years ago to name drivers with a `nutdrv-*` prefix... WDYT? As usual, naming is among the hardest problems in IT ;) Jim On Wed, Feb 22, 2023 at 4:34 PM MODRIS B?RZONIS <modrisb at apollo.lv> wrote:> Jim, > > no, there are no changes in adelsystem. > > Driver's implementation is based on libgpiod, assume this would be natural > to call driver gpio, i2c uses different library to communicate. Yes, any > UPS with open collector pins should work, configuration rules will tune > behavior needed for NUT. > > Just created PR https://github.com/networkupstools/nut/pull/1855 . > > Modris > > On 2/21/23 22:33, Jim Klimov wrote: > > Thanks, looks promising. > > Were there any changes to adelsystem sources? (Not on PC now to check > quickly). > > Also `gpio` naming is too generic (might mean helpers to talk to gpio > pins, e.g. some code shareable by i2c or something of the sort). Does this > handle GPIO UPSes in general (e.g. helped by `rules` line arg), or more > tightly aimed at certain models like yours? > > Style-wise, there's indeed a fair amount of clean-up desireable. Can you > post a PR with this (or improved) codebase, at least to claim a commit in > git history? :) A man page would be nice. > > Jim > > > On Tue, Feb 21, 2023, 20:49 MODRIS B?RZONIS <modrisb at apollo.lv> wrote: > >> Hi! >> >> I have CyberPower CyberShield CSN27U12V UPS. This device don't have >> usual for UPS interface, just open collector pins. I connected these >> pins to GPIO interface on Orange Pi Zero and wrote NUT driver for this >> case. Any interest from NUT community to add this driver to regular >> build tree? >> >> See driver code in attachment. Code is fully functional, needs cleanup >> to match coding guidelines and needs more tests for rules processing >> part. Driver reads GPIO line statuses and transforms them to NUT >> statuses using short rules description parameter in the form of status >> strings and logical operations on line values. >> >> Modris >> >> _______________________________________________ >> Nut-upsdev mailing list >> Nut-upsdev at alioth-lists.debian.net >> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev >> > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://alioth-lists.debian.net/pipermail/nut-upsdev/attachments/20230222/1f8e53f4/attachment.htm>
Jim, generic_gpio is fine for me. This opens some thinking about some common code parts in any kind of NUT driver: when we talk about status handling at some point we have to have determination of how to transform protocol flow into true/false values for states and setting of states is somewhat common. Actually we need to talk about true only. But assume this out of scope of discussion. Very formal naming might be easy from development process set-up, but for end user name with known wording would be better. Modris On 2/22/23 18:08, Jim Klimov wrote:> Great, thanks! > > Also just for context, this sounded reminiscent of one of the first > NUT drivers, `genericups` (for simple contact-closure support, with > IIRC serial-port connections rather than GPIO). > > Nearby there's also a `generic_modbus" name. Wondering if the new > driver should be (similar to) `generic_gpio`. > > @Community verdict: Then there was also an effort some years ago to > name drivers with a `nutdrv-*` prefix... WDYT? > > As usual, naming is among the hardest problems in IT ;) > > Jim > > On Wed, Feb 22, 2023 at 4:34 PM MODRIS B?RZONIS <modrisb at apollo.lv> wrote: > > Jim, > > no, there are no changes in adelsystem. > > Driver's implementation is based on libgpiod, assume this would be > natural to call driver gpio, i2c uses different library to > communicate. Yes, any UPS with open collector pins should work, > configuration rules will tune behavior needed for NUT. > > Just created PR https://github.com/networkupstools/nut/pull/1855 . > > Modris > > On 2/21/23 22:33, Jim Klimov wrote: >> Thanks, looks promising. >> >> Were there any changes to adelsystem sources? (Not on PC now to >> check quickly). >> >> Also `gpio` naming is too generic (might mean helpers to talk to >> gpio pins, e.g. some code shareable by i2c or something of the >> sort). Does this handle GPIO UPSes in general (e.g. helped by >> `rules` line arg), or more tightly aimed at certain models like >> yours? >> >> Style-wise, there's indeed a fair amount of clean-up desireable. >> Can you post a PR with this (or improved) codebase, at least to >> claim a commit in git history? :) A man page would be nice. >> >> Jim >> >> >> On Tue, Feb 21, 2023, 20:49 MODRIS B?RZONIS <modrisb at apollo.lv> >> wrote: >> >> Hi! >> >> I have CyberPower CyberShield CSN27U12V UPS. This device >> don't have >> usual for UPS interface, just open collector pins. I >> connected these >> pins to GPIO interface on Orange Pi Zero and wrote NUT driver >> for this >> case. Any interest from NUT community to add this driver to >> regular >> build tree? >> >> See driver code in attachment. Code is fully functional, >> needs cleanup >> to match coding guidelines and needs more tests for rules >> processing >> part. Driver reads GPIO line statuses and transforms them to NUT >> statuses using short rules description parameter in the form >> of status >> strings and logical operations on line values. >> >> Modris >> >> _______________________________________________ >> Nut-upsdev mailing list >> Nut-upsdev at alioth-lists.debian.net >> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev >> >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://alioth-lists.debian.net/pipermail/nut-upsdev/attachments/20230222/6034d1e7/attachment-0001.htm>
Jim Klimov via Nut-upsdev <nut-upsdev at alioth-lists.debian.net> writes:> Nearby there's also a `generic_modbus" name. Wondering if the new driver > should be (similar to) `generic_gpio`.sound good. It would be nice if there were an abstraction layer for various GPIO access methods, rather than hard-coding linux, even if there is only one implementation of the abstraction. I'm not that clear on GPIO, but I gather there are differences. Or maybe there is already a portable GPIO abstraction library?> @Community verdict: Then there was also an effort some years ago to name > drivers with a `nutdrv-*` prefix... WDYT?I see nutdrv- when used as a driver name to be conent-free.