similar to: QX driver structuring

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

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

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 correctly with nutdrv-qx driver (might be handled better by blazer drivers though), and the overrides

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.

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

I believe the integration is presented as a container on the HA server, so there should be a way to log into it and edit `/etc/nut/ups.conf` or similar during the experiments (generated from YAML settings made in HA GUI somewhere). I have not used it directly, so I can't really help more here. Jim On Wed, Sep 25, 2024 at 5:47?PM Daniele Lamaddalena <dlamaddalena at gmail.com> wrote:

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

Hello, Not really sure. Have not heard about such a brand/model on one hand, and the Home Assistant NUT plugin may be (or not be) limiting the selection of data points it shows from NUT on the other. Can you query the readings with NUT `upsc` client? Also, `nutdrv_qx` is an umbrella driver for many different dialects of "Megatec Q<x>" protocol family. Check the

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?

> Previously, the manufacturer tested this UPS on version 2.6.5-6 NUT for Windows. Thanks for this important detail. For immediate re-testing, I would recommend to use either NUT v2.8.0 already packaged by some distributions in their testing/bleeding-edge repositories (unfortunately, during the almost year since release many distros - especially for LTS versions - did not change recipes to

[please keep the discussion on the nut-upsdev list. thanks!] On Jan 30, 2014, at 10:20 AM, Jos? Sosa wrote: > Dear Mr. Lepple > > I am Leonardo Sosa and I am watching this issue with Rodolfo and Ronaldo. (in copy) > > See below our answers of your questions. > > What should I do now in order to include our code sgs_command in your code blazer_usb.c? As I mentioned to

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

Hello, and thanks for the clarifications. As described, the change does not seem to be too complex on the NUT project's side, the PR posted below took about an hour with some research and this write-up, so I'm not sure I can put a price tag on it :) A donation at https://opencollective.com/networkupstools or https://github.com/sponsors/networkupstools would be welcome though, more so a

Hello Jim, That?s a great help for me. You?re a so kind person ~ Our engineer download the branches f17d9f5 as below and repackage it for test. After testing, The Beta NUT works well with ST VID "0x0483", PID "0xA430. Please tell me how to speed up for merging this to formal version. May I have your predict schedule if possible? Thanks.

aehm.. the innards of nutdrv_qx are not exactly well documented (and vars have somewhat confusing names) -- my fault, sorry. This is another thing that has been on my todo list for a while... Briefly, at the moment, in nutdrv_qx, there are actually two kinds of subdrivers: - 'protocols', which are communication-type-agnostic (i.e. they do not fiddle with serial or USB operations, and are

Answers bellow. 2018-02-28 1:41 GMT-03:00 Daniele Pezzini <hyouko at gmail.com>: > 2018-02-27 14:51 GMT+01:00 Jairo Rotava <jairo.rotava at gmail.com>: > > 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

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

Dear Daniele, i understand perfectly, i'd like to explain you why we choosed to clone the blazer_usb driver: some of our devices uses Voltronic Q1 protocol and we tried the Krauler Subdriver (it was the one with the right "commands", Q1, F, etc.), but the issues were 2: - first: the Krauler Subdriver expects a different number of bytes in answer because in debug i see "Short