Hey there, I got a new UPS (CyberPower PR1500LCDRTXL2Ua) and found the serial drivers don't quite work... So I decided to jump in and make changes to the driver that would hopefully make it happier. I have it working (I really only changed powerp-txt.c) but still have a couple questions... Charles said I should mention them here to talk to anyone interest but specifically Arjen (one of the original authors of the driver) Soooo... Here I am. ;) Where should we start? Essentially, I rewrote powpan_status so it better tolerates strings of different lengths (although I only have the 1 UPS right now, so I can't test against another and different string lengths) I had to make the serial read much longer so it grabs 55bytes instead of the original short list.> 9.843588 read: (55 bytes) => 23 49 31 31 38 2e 30 4f 31 31 38 2e 30 4c 30 31 37 42 > 9.843663 31 30 30 54 30 32 35 48 30 36 30 2e 30 46 30 36 30 2e 30 52 30 35 31 51 30 > 9.843695 30 32 53 90 84 c0 88 80 57 00 81 0dcompared to the original string support in the file, there's now 2 fields of binary data (in ASCII Protocol? seriously? smh) and the S field on this UPS has 4 bytes instead of just 2. (not that it matters I guess... but now it makes me wonder what all the extra information is) (I also guess someone has tried reaching out to CyberPower for docs and been turned down?) Anyway -- in rewriting this, the only part I have left to do to where I'm happy is setting the timeout. Instead of asking for N number of chars and then timing out after a long time, I'd like to ask it for a string (up to the 0x0D). I haven't written that in yet, but will if someone says there's another way -- or I have to do it that way.... so that an incomplete string after time causes a timeout but a string that comes in reasonably soon will be collected -- but not using a fixed number (since it seems these UPSs now have variability in string length between models) and then just parse the string. The parsing part works. I just need to alter the collection part so the timeouts work differently. Any advice from anyone? Thanks, -Ben
On Jan 19, 2016, at 9:37 AM, Ben Kamen <ben at benkamen.net> wrote:> > Hey there, > > I got a new UPS (CyberPower PR1500LCDRTXL2Ua) and found the serial drivers don't quite work...[...]> Essentially, I rewrote powpan_status so it better tolerates strings of different lengths (although I only have the 1 UPS right now, so I can't test against another and different string lengths) > > I had to make the serial read much longer so it grabs 55bytes instead of the original short list. > >> 9.843588 read: (55 bytes) => 23 49 31 31 38 2e 30 4f 31 31 38 2e 30 4c 30 31 37 42 >> 9.843663 31 30 30 54 30 32 35 48 30 36 30 2e 30 46 30 36 30 2e 30 52 30 35 31 51 30 >> 9.843695 30 32 53 90 84 c0 88 80 57 00 81 0d > > compared to the original string support in the file, there's now 2 fields of binary data (in ASCII Protocol? seriously? smh)One thing that you can do to try and cover all the bases with the string lengths is to have "#define TESTING" or something, and have a test function that cycles through the various reply strings, rather than reading from serial. That way, someone without any of these units can test on their own system. For instance: https://github.com/networkupstools/nut/blob/master/drivers/nutdrv_qx.c#L2124 reads from an array defined in the sub-driver: https://github.com/networkupstools/nut/blob/master/drivers/nutdrv_qx_q1.c#L87> and the S field on this UPS has 4 bytes instead of just 2. > > (not that it matters I guess... but now it makes me wonder what all the extra information is) > > (I also guess someone has tried reaching out to CyberPower for docs and been turned down?)Not always the case, but usually we ask for permission to publish the protocols on the NUT website (to assist future developers), and that is often met with silence.> Anyway -- in rewriting this, the only part I have left to do to where I'm happy is setting the timeout. > > Instead of asking for N number of chars and then timing out after a long time, I'd like to ask it for a string (up to the 0x0D).There are also ser_get_line() and ser_get_line_alert(): https://github.com/networkupstools/nut/blob/master/drivers/serial.c#L369 Not sure if there was a specific reason why those weren't used originally, or if this driver predates them.> I haven't written that in yet, but will if someone says there's another way -- or I have to do it that way.... > > so that an incomplete string after time causes a timeout but a string that comes in reasonably soon will be collected -- but not using a fixed number (since it seems these UPSs now have variability in string length between models) and then just parse the string. > > The parsing part works. I just need to alter the collection part so the timeouts work differently.I definitely like your approach. Thanks for moving some of the "magic numbers" to named constants, as well. A few items: * Since v2.6.5, some of the string functions were renamed. rtrim() -> str_rtrim(), for instance. * If you are taking out a block of code, "#if 0" is better than comment characters (which don't nest), and removing it completely is even better (fewer false positives when searching). If nothing else, it's in version control. Diff attached. Thanks, -- Charles Lepple clepple at gmail -------------- next part -------------- A non-text attachment was scrubbed... Name: powerp-txt.c.diff Type: application/octet-stream Size: 9129 bytes Desc: not available URL: <http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20160128/a3f287bf/attachment.obj>
I got 2 copies of that email. weird. Was it just me? Thanks for the look and return diff. I'll take a look. -Ben
On 2016-01-28 8:18 AM, Charles Lepple wrote:> I definitely like your approach. Thanks for moving some of the "magic numbers" to named constants, as well.Thanks. Always nice to have real coders sanity check anything I've written with a "thumbs up" response. (I'm more a hardware guy) And sscanf was working like poo -- so I figured I'd parse it differently with something that didn't seem so sensitive.> A few items: > > * Since v2.6.5, some of the string functions were renamed. rtrim() -> str_rtrim(), for instance.I'll take a look at the latest.... as mentioned, 2.6.5 is what's on my CentOS system with nothing later (yet) so I just downloaded the SRPMS to work on. but I also have 2.7.3 downloaded -- so I'll see what I can do with that.> * If you are taking out a block of code, "#if 0" is better than comment characters (which don't nest), and removing it completely is even better (fewer false positives when searching). If nothing else, it's in version control.Yea - the comments were just temporary to keep the old stuff in my view while I was re-writing around it. Then once it worked and I planned on removing it. I'll send along something more finished once I'm done. Thanks again! -Ben
Hey all, I recently got an RMCARD205 for my Cyber UPS.... if I use no MIBS line in the config file, I get this:> Network UPS Tools - UPS driver controller 2.6.5 > Network UPS Tools - Generic SNMP UPS driver 0.68 (2.6.5) > No matching MIB found for sysOID '.1.3.6.1.4.1.3808.1.1.1'! > Please report it to NUT developers, with an 'upsc' output for your device. > Going back to the classic MIB detection method. > Detected PR1500LCDRTXL2Ua on host 192.168.125.10 (mib: cyberpower 0.1) > Network UPS Tools - Generic SNMP UPS driver 0.68 (2.6.5) > Detected SMART-UPS 3000 RM on host 192.168.125.7 (mib: apcc 1.2) > [shop] Warning: excessive poll failures, limiting error reporting > [shop] Warning: excessive poll failures, limiting error reportingIf I use the mibs = cyberpower it works as somewhat expected:> > Network UPS Tools - UPS driver controller 2.6.5 > Network UPS Tools - Generic SNMP UPS driver 0.68 (2.6.5) > Detected PR1500LCDRTXL2Ua on host 192.168.125.10 (mib: cyberpower 0.1) > Network UPS Tools - Generic SNMP UPS driver 0.68 (2.6.5) > Detected SMART-UPS 3000 RM on host 192.168.125.7 (mib: apcc 1.2) > [shop] Warning: excessive poll failures, limiting error reporting > [shop] Warning: excessive poll failures, limiting error reportingbut could use updating as the upsc output is kinda lacking some desired measurements (that I get with APC) ... I see the current is 2.7.x but I'm on CentOS/RH 6.x which seems to have stalled out at 2.6.5 Does 2.7 have the newer fancy MIB and I can just compile up and install manually? I'm assuming RH/CentOS 6 won't be getting anymore updates. :( I'll look around some more for an RPM for 6.x Cheers, -Ben Also, when I go to : http://networkupstools.org/docs/man/snmp-ups.html and click on the link at the bottom: http://www.networkupstools.org/protocols/snmp/ I get a 404 error. (just an FYI)
Build from source, and done . . . wasting your time looking for a less out of date RPM is pointless. . . RPM, .deb, etc are almost always downrev. . . - Tim On June 10, 2017 2:06:42 PM CDT, Ben Kamen <ben at benkamen.net> wrote:>Hey all, > > I recently got an RMCARD205 for my Cyber UPS.... > >if I use no MIBS line in the config file, I get this: > > >> Network UPS Tools - UPS driver controller 2.6.5 >> Network UPS Tools - Generic SNMP UPS driver 0.68 (2.6.5) >> No matching MIB found for sysOID '.1.3.6.1.4.1.3808.1.1.1'! >> Please report it to NUT developers, with an 'upsc' output for your >device. >> Going back to the classic MIB detection method. >> Detected PR1500LCDRTXL2Ua on host 192.168.125.10 (mib: cyberpower >0.1) >> Network UPS Tools - Generic SNMP UPS driver 0.68 (2.6.5) >> Detected SMART-UPS 3000 RM on host 192.168.125.7 (mib: apcc 1.2) >> [shop] Warning: excessive poll failures, limiting error reporting >> [shop] Warning: excessive poll failures, limiting error reporting > >If I use the mibs = cyberpower > >it works as somewhat expected: > >> >> Network UPS Tools - UPS driver controller 2.6.5 >> Network UPS Tools - Generic SNMP UPS driver 0.68 (2.6.5) >> Detected PR1500LCDRTXL2Ua on host 192.168.125.10 (mib: cyberpower >0.1) >> Network UPS Tools - Generic SNMP UPS driver 0.68 (2.6.5) >> Detected SMART-UPS 3000 RM on host 192.168.125.7 (mib: apcc 1.2) >> [shop] Warning: excessive poll failures, limiting error reporting >> [shop] Warning: excessive poll failures, limiting error reporting > > >but could use updating as the upsc output is kinda lacking some desired >measurements (that I get with APC) ... I see the current is 2.7.x but >I'm on CentOS/RH 6.x which seems to have stalled out at 2.6.5 > >Does 2.7 have the newer fancy MIB and I can just compile up and install >manually? > >I'm assuming RH/CentOS 6 won't be getting anymore updates. :( > >I'll look around some more for an RPM for 6.x > >Cheers, > > -Ben > > >Also, > >when I go to : http://networkupstools.org/docs/man/snmp-ups.html and >click on the link at the bottom: >http://www.networkupstools.org/protocols/snmp/ I get a 404 error. (just >an FYI) > >_______________________________________________ >Nut-upsdev mailing list >Nut-upsdev at lists.alioth.debian.org >http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev-- Sent from my Android device with K-9 Mail. Please excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20170610/f87d3b54/attachment.html>