search for: nutdrv

...s 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 the author of nutdrv_qx, but in the mean time, he also wrote this portion of the developer documentation: http://networkupstools.org/docs/developer-guide.chunked/ar01s04.html#nutdrv_qx-subdrivers In your case, it sounds like you can start from the q1 driver - maybe modify it in-place first to verify assumptions, then...

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 30 30 30 2e 30 20 30...

> 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.

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?

...5-x-2-USB-LCD-Display/UPS0171/?gclid=Cj0KEQjw3ZS- BRD1xu3qw8uS2s4BEiQA2bcfMwMPzsshzLqNK3E8NoAKQ6PPWRW589_ zkYZ5YZDInb4aAuqK8P8HAQ). It comes with software for windows/linux called UPSmart1.5 which connects and monitors this UPS. I am unable to use it with NUT at present. It seems that the driver nutdrv_qx could be made to support it but does not at present. I am testing with the command: ./nutdrv_qx -u root -a powercool -DDDDD -x vendorid=0001 -x productid=0000 On my github https://github.com/mattwire/powercool-ups you can see some debug data. The file powercool_usbmon.txt is captured using wi...

...inux, 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.

...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.

...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. > > > > _______________________________________________ > Nut-upsdev mailing list > Nut-upsdev at alioth-lists.debian.net > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsd...

...or 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...

Got a community question at https://github.com/networkupstools/nut/issues/2466 with at least two users (and UPSes) in trouble. Curiously, they identify as 067b:2303 Prolific Technology like a common USB-Serial dongle brand. Experiments with blazer and nutdrv-qx got no reasonable response from the devices. Jim -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://alioth-lists.debian.net/pipermail/nut-upsdev/attachments/20240624/ac547d28/attachment.htm>

Got a community question at https://github.com/networkupstools/nut/issues/2466 with at least two users (and UPSes) in trouble. Curiously, they identify as 067b:2303 Prolific Technology like a common USB-Serial dongle brand. Experiments with blazer and nutdrv-qx got no reasonable response from the devices. Jim -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://alioth-lists.debian.net/pipermail/nut-upsdev/attachments/20240624/ac547d28/attachment.htm>

Hi, I had an issue where after returning the power from a shutdown.return the ups would do another shutdown.return during the boot, and kept this forever. After some investigation I found the problem is a bug on the ups - TSSHARA model, driver nutdrv_qx: every time I shutdown with return, and reconnect the usb after the power is back it would start another shudown.return cycle. When I used my rapsberry pi on it they would cycle forever. I tested the shutdown.return using the upscmd and I didn't see this behavior, so I finally find out that...

....com/networkupstools/nut/issues/2466 > <https://github.com/networkupstools/nut/issues/2466> with at least two > users (and UPSes) in trouble. > > Curiously, they identify as |067b:2303 Prolific Technology| like a > common USB-Serial dongle brand. Experiments with blazer and nutdrv-qx > got no reasonable response from the devices. > > Jim > The cure Jim, is eliminate the prolific by replacing it with a FTDI dongle. Prolific has a bug in its wakeup, throwing away the first byte rx'd. I threw mine into the out bin 2 decades ago. Was trying to use it to ta...

On 6/24/24 12:50, gene heskett via Nut-upsuser wrote: > On 6/24/24 11:30, Jim Klimov via Nut-upsuser wrote: >> Curiously, they identify as |067b:2303 Prolific Technology| like a >> common USB-Serial dongle brand. Experiments with blazer and nutdrv-qx >> got no reasonable response from the devices. >> >> Jim >> > The cure Jim, is eliminate the prolific by replacing it with a FTDI > dongle. Prolific has a bug in its wakeup, throwing away the first byte > rx'd. I threw mine into the out bin 2 decades ago. W...

...o, this is to let you know I will start working on a modbus driver for the PhoenixContact QUINT-UPS industrial DC UPS, model 2320461. https://www.phoenixcontact.com/online/portal/us?uri=pxc-oc-itemdetail:pid=2320461&library=usen&pcck=P-22-07-01-01&tab=1 I will reuse some parts of the nutdrv-modbus branch, but this will be a model specific driver, not a generic one. Unfortunately generic drivers and autodetection don't seem to make sense in the modbus world. I hope the phoenixcontact-quint-modbus drive name will be ok, I'll start by branching off the current master. I hope I&...

...> > > > I had an issue where after returning the power from a shutdown.return the > > ups would do another shutdown.return during the boot, and kept this > forever. > > After some investigation I found the problem is a bug on the ups - > TSSHARA > > model, driver nutdrv_qx: every time I shutdown with return, and reconnect > > the usb after the power is back it would start another shudown.return > cycle. > > When I used my rapsberry pi on it they would cycle forever. > > Jairo, what's the exact model of the UPS? > TS Shara Soho II &gt...