similar to: blzr_voltronic.c

Daniele, Thanks again for your work on both the voltronic and blzr drivers. To get the most exposure to new drivers, what we have typically done in the past is to rename the existing driver as *-old, so that users get the new driver by default when they upgrade (but the old driver is still available if there are regressions). This is how we are incorporating Michal's apcsmart updates. On

On Nov 1, 2013, at 9:03 AM, Charles Lepple wrote: > But if blzr supersedes both voltronic and blazer, I propose we rename blazer_{ser,usb} to blazer_{ser,usb}_old, then rename blzr* to blazer*, and revert the voltronic merge. Dan, The pull request against master looks good - thanks! What do you think about the renaming of blazer to blazer_old, and making blzr the new blazer driver? I still

[apparently the list didn't get the message, probably because it exceeds the 40kb threshold, so here it is in all its glory with my reply] On Mon, 3 Sep 2018 at 14:32, Gabriele TAORMINA <gabriele.taormina at legrand.com> wrote: > > Dear Daniele, > > > "I fixed a few issues, and pushed your changes (amended) to this > > temporary branch:

In my opinion, there might be just one problem: the blzr driver doesn't provide anymore two splitted drivers (serial and usb), so this isn't going to be a 'silent update' for those using these drivers (should we provide symlinks or the like?). If this doesn't sound like a problem to you, I'll take care of the rename. Plus, if you could take a look to the blazer-fix pull

Dear Daniele, I have some news regarding the Driver: I applied the patch you sent me (https://github.com/zykh/nut/tree/issue-441) and it works correctly (obviously in Level 5 of Debug I see "missing CR...etc.."). As for now there are 2 modification I'd like to suggest you: - For Online Type UPSs the Megatec protocol describes that the battery voltage is provided in the form of V

[forwarded without attachments, for real this time] > Begin forwarded message: > > From: Gabriele TAORMINA <gabriele.taormina at legrand.com <mailto:gabriele.taormina at legrand.com>> > Subject: Re: [Nut-upsdev] Adding drivers to NUT? > Date: August 27, 2018 at 6:03:55 AM EDT > To: Daniele Pezzini <hyouko at gmail.com <mailto:hyouko at gmail.com>> >

2014-01-31 hyouko at gmail.com <hyouko at gmail.com>: > I changed a couple of things: > - https://github.com/zykh/nut/commit/ebae0e0e499e7983b4f26562451255a39abb023b#diff-38221201bf335e4da4e2dc77d5c6b3c2R478 > - https://github.com/zykh/nut/commit/ebae0e0e499e7983b4f26562451255a39abb023b#diff-38221201bf335e4da4e2dc77d5c6b3c2R482 Better links:

I added the sgs subdriver to nutdrv_qx: https://github.com/zykh/nut/tree/ts-shara (I assumed Rodolfo - surname? - is the author of the code, do you want me to change it?) I changed a couple of things: - https://github.com/zykh/nut/commit/ebae0e0e499e7983b4f26562451255a39abb023b#diff-38221201bf335e4da4e2dc77d5c6b3c2R478 -

On Jun 8, 2016, at 7:47 PM, hyouko at gmail.com wrote: > >> However, this was not an error I was expecting to see when rebuilding: >> >> http://buildbot.networkupstools.org/public/nut/builders/Debian-website/builds/55/steps/shell/logs/stdio >> [...] >> Makefile:796: *** target pattern contains no '%'. Stop. >> >> Any ideas? > >

https://bugzilla.netfilter.org/show_bug.cgi?id=1333 Bug ID: 1333 Summary: 1.8.2: build fails with gcc 9 Product: iptables Version: unspecified Hardware: x86_64 OS: All Status: NEW Severity: enhancement Priority: P5 Component: iptables Assignee: netfilter-buglog at

On Nov 7, 2014, at 5:31 PM, hyouko at gmail.com wrote: >> Sure enough, it turned off after about 30 seconds (t=228). I unplugged it for about five seconds, and it came back on three minutes after I plugged it back in. However, the bypass bit inversion might be responsible for this: >> >> 228.304623 send: 'Q1' >> 228.515426 read: '(119.0 119.0 000.0 000

On Dec 7, 2013, at 5:43 AM, Denis Yantarev wrote: > Ippon Back Power Pro responses are always padded to 64 bytes beyond \r payload terminator. When checking that command was successful (i.e. not echoed back) code relies on the response length reported by blazer_command which will always be 64. To fix this ippon_command should return actual payload length. This change also affects

On Apr 4, 2015, at 7:19 PM, Richard Flint <richard.flint at gmail.com> wrote: > More extensive debugging by running the driver sudo ./nutdrv_qx -u root -a MY_UPS -DDDDDD indicates the driver works normally then will randomly stop working at stop "send: QS". The debug logs show values successfully retrieved repeatedly until something like: > .... > Quick update... >

On Jul 18, 2019, at 5:09 AM, Patrick M. Hausen wrote: > > Hi! > >> Am 18.07.2019 um 05:02 schrieb Charles Lepple <clepple at gmail.com>: >> @zykh recommends libusb-compat-1.0. I have not tested it recently, but when I last did, I had to run the driver as root on FreeBSD (probably 11.1?): > > I’ll check, thanks. > > Just FYI: the FreeBSD ports maintainer

Sorry for the delay. >> make > Making all in protocols > make[1]: Nothing to be done for `all'. > make[1]: Nothing to be done for `all-am'. > cd nut/docs; /Applications/Xcode.app/Contents/Developer/usr/bin/make > html-chunked pdf > make[1]: Nothing to be done for `html-chunked'. > make[1]: Nothing to be done for `pdf'. > cd nut/docs/man;

-------------------------------------------------- From: <hyouko at gmail.com> Sent: Tuesday, July 08, 2014 12:16 AM To: "Hill" <hill at fermot.com.pl> Cc: "Charles Lepple" <clepple at gmail.com>; <nut-upsuser at lists.alioth.debian.org> Subject: Re: [Nut-upsuser] Lupus 500 MEC0003 Problems >> Everything looks fine apart from ups.beeper.status

On Nov 5, 2015, at 11:33 AM, Rob Groner <rgroner at RTD.com> wrote: > > Having dealt with the USB portion of our UPS, I?m now reviewing our serial port communication. I?ve looked over some of the drivers in NUT to see how they handle it so I can get an idea of what the ?standard? is for how to accomplish it. I?d like to do something simple and human readable. The de facto standard

On Dec 28, 2014, at 4:38 PM, hyouko at gmail.com wrote: > So, I think this can be solved replacing all the occurrences (3) of > 'echo -e' with 'printf' in Makefile.am, see: > https://github.com/zykh/nut-website/tree/issue7 > Does it solve the problem? Are there other hiccups? As expected, printf works for me on OS X 10.9 (Mavericks) as well. The only thing we need to

Hi Thank you very much for the feedback. I will download and try to get it working on the Raspberry Pi. Regards Tom On Sun, Feb 14, 2016 at 1:49 AM, hyouko at gmail.com <hyouko at gmail.com> wrote: > > I have the RCT 3KVA Axpert solar hybrid inverter. It is also known as > the > > MPP Solar PIP-MS series, the IPS-4000WM and the Voltronic Axpert MKS. I > am > >

> However, this was not an error I was expecting to see when rebuilding: > > http://buildbot.networkupstools.org/public/nut/builders/Debian-website/builds/55/steps/shell/logs/stdio > [...] > Makefile:796: *** target pattern contains no '%'. Stop. > > Any ideas? I think we don't support colons in names of files and dirs: -