similar to: PR to test for users of Qx devices (blazer and nutdrv_qx)

Jim Klimov via Nut-upsuser <nut-upsuser at alioth-lists.debian.net> > > Cheers, > > One PR waiting to get into 2.8.1 release timeframe is https://github.com/networkupstools/nut/pull/1652 stemming from issue https://github.com/networkupstools/nut/issues/1279 > > The gist of it is that "battery.voltage" and "battery.charge" were not always reported

Jim Klimov via Nut-upsuser <nut-upsuser at alioth-lists.debian.net> > > Cheers, > > One PR waiting to get into 2.8.1 release timeframe is https://github.com/networkupstools/nut/pull/1652 stemming from issue https://github.com/networkupstools/nut/issues/1279 > > The gist of it is that "battery.voltage" and "battery.charge" were not always reported

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

Hi, I would like to report that Tuncmatik Newtech Pro 1 KVA (http://www.tuncmatik.com/en-US/productDetail.asp?RecID=290) works with nut(2.4.1) blazer_usb, blazer_ser and megatec drivers. The UPS came with an usb cable and a java based software for both linux and windows, named ViewPower (http://www-power-software-download.com). This UPS has double interface a USB interface and a serial

On Wed, Aug 31, 2016 at 4:19 AM, Matthew Wire <mjw at mjwconsult.co.uk> wrote: > Further analysis it looks like the status string matches the q1 subdriver > but a lowercase "f" is sent to request it instead of "Q1\r". What do you > think? It is certainly possible - there is no comprehensive protocol guide for all these variants. I was hoping we would hear from

Hi, it does communicate using the fabula subdriver but I don't get any of the values parsed. If I execute: ./nutdrv_qx -a powercool -DDDDD -x subdriver=fabula -x vendorid=0001 -x productid=0000 I get the following returned: 12.242991 upsdrv_updateinfo... 12.243047 Quick update... 12.243069 send: Q1 12.243087 command index: 0x03 12.249983 read: (47 bytes) => 28 30 30 30 2e 30 20

> On Oct 10, 2016, at 4:29 PM, Matthew Wire <mjw at mjwconsult.co.uk> wrote: > > Here is the complete log for two minutes from startup. thank you compressed to fit on the mailing list. > > On 9 October 2016 at 23:41, hyouko at gmail.com <hyouko at gmail.com> wrote: > > 12.243069 send: Q1 > > 12.243087 command index: 0x03 > > 12.249983 read: (47

Thanks for the log - apparently we always get valid (apart from 0.191312) but empty replies, not only for index 0x03, but also for the other queried index (0x0c). I've re-looked at the logs you posted on GitHub, but I don't see anything exotic going on there. Maybe we're missing some sort of handshaking or the like: can you post the whole captures/logs, right from when you plug the

Hi Charles, I've added 3 more files to github. https://github.com/mattwire/powercool-ups/blob/master/wireshark-UPSmart-startup.pcapng - captures startup of UPSmart software and continues for about 5 minutes. https://github.com/mattwire/powercool-ups/blob/master/wireshark-UPSmart-ups_off-on.pcapng - UPSmart software is running, UPS is OFF. UPS is switched on and connects to software.

Wow just seen this screenshot. I did not know it did that. Is this the port is ask for? Can I go to it's webpage and some port to see this type screen? -Raymond Day On 11/3/2016 6:39 PM, Matthew Wire wrote: > https://github.com/mattwire/powercool-ups/blob/master/UPSmart_connected.png > - is a screenshot of the UPSmart software when connected (shows some > values from UPS).

Thanks again for the logs. Now... let's assume those interrupts are needed to get valid values... well, we can't do exactly the same thing, but let's start from this one: https://github.com/zykh/nut/tree/nutdrv_qx_fabula-zero Please, test nutdrv_qx (with subdriver 'fabula') from that branch and post the output of it running with debug-level of 5.

Cheers, Have we got any experts on nutdrv_qx structure online? https://github.com/networkupstools/nut/issues/1987 would benefit from suggestions on wedging a PoC-standalone driver into it as a subdriver... Jim -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://alioth-lists.debian.net/pipermail/nut-upsdev/attachments/20230812/a6e1afa9/attachment.htm>

Cheers all, Got an interesting report at https://github.com/networkupstools/nut/issues/2208 about Qx devices that do not respond to NUT unless `upsmart` somehow inits them first (until a re-plug). This behavior is something I've heard of a couple of times, and now there are pcap captures to help smart folks make heads or tails of it and teach `nutdrv_qx` the optionto initialize the UPS

Matthew, I've looked briefly at the files you uploaded to GitHub and it seems to me that the device is like something that should work with the 'fabula' USB subdriver (and 'megatec' protocol): what are the issues you are experiencing and that prevent the driver to work?

Further analysis it looks like the status string matches the q1 subdriver but a lowercase "f" is sent to request it instead of "Q1\r". What do you think? ---------- Forwarded message ---------- From: "Matthew Wire" <devel at mrwire.co.uk> Date: 30 Aug 2016 22:51 Subject: powercool 1500VA USB UPS To: <nut-upsuser at lists.alioth.debian.org> Cc: I have

Hi all, Arjen can you enlighten me about the function of the blazer upsdrv_shutdown function. I think they are in the wrong order. Regards Kjell

Hi, I've being using nut 2.2.2 (Debian Lenny) via megatec_usb driver for IPPON Back UPS 600. Then I upgraded to nut 2.4.3 (Debian Squeeze) with broken megatec_usb. I moved to blazer_usb, it connected IPPON. [myups] driver = blazer_usb port = /dev/usb/hiddev0 desc = "Local UPS" #from megatec.c: batteries[] = {{ 12.0, 9.0, 16.0, 9.7, 13.7, 0.0 },

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

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

On Apr 6, 2014, at 8:43 AM, alezz wrote: > Hi Charles, > Thanks for reply. > I've took a look at the code you suggested me and tested it with my device. > That patch implements tcp connection in serial.c, this is a more > flexible approach, as it is applicable to all serial drivers. However > the drivers then make ioctl calls to setup the tty port, and these fail. > At