Problem with NUTDRV_QX, subdriver armac - unable start driver #1978
Labels
bug
impacts-release-2.8.0
Issues reported against NUT release 2.8.0 (maybe vanilla or with minor packaging tweaks)
Qx protocol driver
Driver based on Megatec Q<number> such as new nutdrv_qx, or obsoleted blazer and some others
Milestone
Comments
jimklimov
added
the
Qx protocol driver
|
Hello, sorry to hear about that, perhaps your device is different from ones handled by the sub-driver (could be a case of "same ID, unrelated OEM"). FWIW, it was added in #1250 (see also #1238) so possibly @blaa could troubleshoot this better. Could there be some bug in the new code?.. The subdriver comments suggest looking at |
|
But the same UPS working ok with this driver,when I connect it to Asus router with asus-merlin firmware and nut installed via entware-ng ;) Problem is on orangepi with Armbian Bookworm :) |
|
Ok, that is a very new piece of information, I believe :) Can you check if they ship same or different NUT and driver versions? Looking at https://github.com/Entware/entware-ng-packages/blob/master/net/nut/Makefile I see it has 2.7.4 (so perhaps falls back to another subdriver/protocol?) and the repo is archived... Also, if you built your own NUT - try just in case with the master branch. Some fixes did accumulate over the past year... maybe something there impacts this case too? UPDATE from 2024: The "entware-ng-packages" repo is archived. There is a newer https://github.com/Entware/entware-packages/blob/master/net/nut/ (2.8.1 at the moment, almost up to date) with http://bin.entware.net/Readme.txt (from 2020) claiming:
|
|
Ok on armbian I will try to compile via git clone :) About version on asus - actually I re-flashed this router so I'm unable to check version of working NUT . I copy 1:1 config from asus to armbian and as on first post - it doesn't work. So i will check with version via git clone, and if no efftects maybe I try build 2.7.4 on Armbian from sources |
|
Well, can't recommend 2.7.4 nowadays - it is over 7 years old now. My guess would rather be that if the UPS worked with it, there could be a different subdriver/protocol involved -- and you could try its 2.8.0+ version instead of At least, for the "1:1 config" part, the 2.7.4 driver would have probably refused to start with a then-unknown config option, I hope. At worst it might have fallen back to auto-detection (as if no option - which is another thing you can try), but I think it should have errored out. |
|
1:1 config I men copy driver name etc from old config, not copy 1:1 files :) |
|
Seems like a correctly parsed message. (They get send in chunks of ~4 bytes in this protocol, so it means the proto mostly works fine). The Armac subdriver did not parse the contents of this string though; only glued it together from USB and passed to already existing driver. That worked for my UPS/nut version. Maybe something changed in Qx (?) driver that causes it to fail. Anywho - I can try to replicate on my hardware and make some fix, but it might take me 2 weeks to get started. Drop me a note if you manage to get it running (and how. ;d) or if you need some assistance. I'm unsure which version I have running, and I have a bit different UPS. |
|
So, after reinstall nut via clone repository it works :) and get data: |
|
Has there, by any chance, been progress on this? I've purchased the 'new' Armac PF1 unit and tried getting it hooked up to UNRAID via NUT, but all three recommended drivers get me nowhere. My On version 2023.07.24a for UNRAID I tried: and I get: By trying to add It looks like it should have been added https://github.com/networkupstools/nut/blob/master/drivers/nutdrv_qx.c, but it obviously didn't or the Unraid version is not yet up to speed. Any assistance would be greatly appreciated! |
|
@convicte : Hello again. What sort of "progress" here are you asking about? Driver is present, problem solved on NUT side. Poke the distro (unRaid) to package a newer NUT version. Ok, part of the NUT-side problem may be that it was added after 2.8.0 so a release should be completed (trying to find time to look at some puzzling issues before that), but that distro ships an even older version. Or am I missing something? PS: your |
|
Thank you, so very much for the prompt reply. I am not sure, we've interacted before, but I ask for so much assistance here and there to get my strange creations working, there is a good chance we did.
I don't know honestly who is ahead of who, and thus I decided to start at the source. If you feel everything is in place for the vanilla NUT to have the
Any assistance would be greatly appreciated! |
|
From your logs this looks like nut 2.7.4.1. Unraid should upgrade it's base version. |
|
Working on that now! |
|
We've seemingly exhausted all the improvements required on the Unraid side to get the driver to work but still no joy.
@blaa would you be able to point me to what I need to provide to receive assistance in that regard? I've also tested it with the Richcomm driver, just as a last resort and I get some communication, but still a failure:
|
|
BTW, here is everything we've tested today: https://forums.unraid.net/topic/60217-plugin-nut-v2-network-ups-tools/page/32/ |
|
So, let's sum up.
Recheck anyhow, because under 2.7.x this could not have worked.
We here have pretty no idea what rc.nut start exactly does, so starting some more basic commands + current config file would certainly help. Try starting the driver as bdkacz did with -DDD: /path/to/nutdrv_qx -DDD -a poddasze Try to interpret the output, maybe fix something and paste here the result.
Edit: One of my debug commands I used: It should work the same as a correct config + the previous command with -a, -u root maaaybe miiiight be interesting. |
|
@blaa, thank you so much for the assistance thus far. Here is the output of the I am certain I tried with both generic configuration, as discussed above, and Here is my config, though I constantly wonder if syntax matters here, such as indentation and "" around various variables, since even in this there you indicated yours differently than the original reported and both seem to work.
I've tried both with the entries line by line, and with this gap (since it's said to have been a bug which required this spacing to work).
Default passwords for the moment:
I hope this helps! Thank you in advance!!! |
|
I've increased debug logging even further to -DDDD and there is clearly sensible data flowing, where I can spot the high input voltage around 245V, the output regulated voltage of 230V, the 50Hz frequency, where the rest is probable usage at 0 (since the draw is disconnected), etc. This said, the driver struggles to parse and process it correctly - though I have no idea why. It's a really large data dump, so I moved it to a pastbin not to generate an even worse code wall: Looking forward to everyone's input. |
|
Good you tried -D; in the previous dump I was wondering why the Q1 command is not being tested at all. And well - it is executed, but at the end of reading, when the almost whole message is already read the driver gets Relevant part: memset(buf, 0, buflen);
bufpos = 0;
while (bufpos + 6 < buflen) {
size_t bytes_available;
/* Read data in 6-byte chunks */
ret = usb_interrupt_read(udev,
0x81,
(usb_ctrl_charbuf)tmpbuf, 6, 1000);
/* Any errors here mean that we are unable to read a reply
* (which will happen after successfully writing a command
* to the UPS) */
if (ret != 6) {
upsdebugx(1, // <-- We end up here.
"interrupt read error: %s (%d)",
ret ? nut_usb_strerror(ret) : "timeout",
ret);
return ret;
}
upsdebugx(4,
"read: ret %d buf %02hhx: %02hhx %02hhx %02hhx %02hhx %02hhx >%c%c%c%c%c<",
ret,
tmpbuf[0], tmpbuf[1], tmpbuf[2], tmpbuf[3], tmpbuf[4], tmpbuf[5],
tmpbuf[1], tmpbuf[2], tmpbuf[3], tmpbuf[4], tmpbuf[5]);
bytes_available = (unsigned char)tmpbuf[0] & 0x0f;
if (bytes_available == 0) {
/* End of transfer */
break; // <-- This is not being hit (because supposedly there are still 3 bytes to be read)
}
memcpy(buf + bufpos, tmpbuf + 1, bytes_available);
bufpos += bytes_available;
if (bytes_available <= 2) { // <--- This won't be hit here (3), maaybe it should.
/* Slow down, let the UPS buffer more bytes */
usleep(15000);
}
}At this point to move forward I guess it would be best if you had source code for nut on a device and be able to tweak it a bit and test it... then we can improve the driver to work better in your case. But it would need some try&error. EDIT: More zeroes, which maybe caused the message to be finalized differently. We can detect the \0x0d for example instead of expecting bytes_available to be 0. |
|
You seem to think I know what I am doing around code revision... a grave error on your part... lol I am being honest when I am well over my head with something.
I am there with you, though how to proceed is something I'll have to rely on your expertise. |
|
We could try realtime talk tomorrow. Signal? Element/Matrix? Discord maybe? I've a simple idea for an additional check that would work with your UPS. But probably would have to build it myself and send you nutdrv_qx driver binary? Your device is a simple x86_64 for this unraid? Or something more exotic? Would be easier when I'm home and can test with a device. This could be as easy as: But also interrupt timeout could be handled as "success" if some bytes were previously read. |
|
Discord works for me - same nick there! I am working from home and on my PC, so have access to the hardware at a moment's notice. The NUT packaged used to install it is a nut-2.8.0-x86_64-1.txz, so I guess the answer to your questions is YES. Thank you so very much for all the assistance! |
|
Here you have two binary ELF files (executables). Build on a Debian Stable. The major problem might be that I have different library versions and they won't simply run on unraid. |
|
I am trying to put them into the right folder now. Lets see if I can run it the same way I did before just with the new file name. |
|
There are either a differences in protocol, or just protocol works as supposed but in this case the revengineered version falls short. Following change seems to read the Q1 command just fine, but I think it won't work on other devices like this. ;) Transmission sample: When I'm home I can test it against my own and create a patch that should work on both just fine. @bdkacz if you would be so kind to try to run the nutdrv_qx with -DDDD and paste your transmission fragment related to the Q1 command I'd be grateful. ;-) More examples, the better. |
|
Would you please post a pull request so it also works after NUT upgrades for you and others? ;) |
jimklimov
added
bug
impacts-release-2.8.0
jimklimov
added a commit
to jimklimov/nut
that referenced
this issue
Jul 31, 2023
…etworkupstools#1978] Authored by Tomasz bla Fortuna @blaa at networkupstools#1978 (comment) Signed-off-by: Jim Klimov <[email protected]>
jimklimov
added a commit
to jimklimov/nut
that referenced
this issue
Jul 31, 2023
…upstools#1978] Authored by Tomasz bla Fortuna @blaa at networkupstools#1978 (comment) Signed-off-by: Jim Klimov <[email protected]>
jimklimov
added a commit
to jimklimov/nut
that referenced
this issue
Jul 31, 2023
Signed-off-by: Jim Klimov <[email protected]>
|
Cheers, posted the PR with patch copied from above, moving the programming part of discussion there to #2003 - got a question... |
|
I was wondering how this is even possible. Tomorrow night I have a graveyard shift and i would like to try to build @blaa version in order to test it and see if it works. Thanks meanwhile. really wired. |
|
@Novocaine85 which UPS do you have? This was reverse engineered protocol based on my device solely. It's nice that currently it's corrected with a debug info from other devices. Hope it works nice, and if not - send me -DDDD outputs from nutdrv_qx driver. ;) |
My UPS is a Vultech V2000 (https://www.vultech.it/en/serie-pro/640-ups-2000va-line-interactive-lcd-gruppo-di-continuita-8057284627203.html). Now: this is what i got from the UPS launching it from NUT installed from apt (debian bookworm, v2.8.0) now i'll try to build your version. |
what's wrong? |
|
Add another -D please! With four, it shows the messages as they are read from the UPS. I see no initial "cleaning" messeges, but maybe that's because of 3x D. In general it failed because 3 initial Q1 queries failed, but the reason can't be seen. |
|
|
Are you certain this has the latest changes? It reports 2.8.0-2272-g3a11558e6 - the changes are not yet merged. Latest are here: https://github.com/blaa/nut.git PR should land shortly, but tests like this will help. ;) The problem I see in your log seems like something that SHOULD HAVE BEEN FIXED by this last PR, so if it's not, I'll need to dive in, but we must check if your version is right. |
|
I confirm I've git cloned your version. let me double check just to be sure whops, you are right. i was following the instructions inside the INSTALL.md but i forgot to change the url. Sorry I'll try again now. |
|
|
Haha, great. This is new version indeed. And - some new behaviour... Looks like your UPS terminates messages with a null byte instead of \r (0x0d). I can add support for this behaviour tomorrow I guess. It should be easily compatible. |
|
thank you for your support meanwhile :) |
|
@Novocaine85 I've even hacked a possible solution - |
|
|
So... now it seems to read the messeges OK each time, but the upper driver (qx) doesn't understand them. Maybe it NEEDS \r instead of \x00. Or... the \x00 should not be included in the length. Two options to try. Third one - it doesn't understand the output at all and some support for Qx is required, but as I understand it used to work. I pushed the first solution - you can try it. edit: this time git pull won't do, I amended the commit. git fetch + git reset --hard master probably? My current commit hash is: d488538 |
|
|
Still |
|
add me on discord: icchan85 |
|
I added a testcase locally with your data. The command is read correctly(?) after the change, but your UPS has less status bits (assuming 0x00 ends message) Maybe previously it worked sometimes because the 0x00 wasn't terminating the message and it was longer for wrong reasons. Or something changed in NUT and master doesn't handle it, but previous version did (?). At least table in nutdrv_qx_q1.c doesn't allow your response. It could be added probably ok, but we'd need a description of the bits (or maybe assuming the first work the same, and later should be ignored). For example which bits are enabled when on line, on battery, during the test. Hm. Can you paste a response to Q1 query when UPS is on battery? edit: Alternatively we can try reading while IGNORING null bytes. Seems weird, but maybe this will read complete status. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hello
I have this UPS http://armac.pl/oferta/ups-office-line-interactive-o850elcd/
I compiled the latest nut-2.8.0 from sources from file nut-2.8.0.tar.gz
Here is my lsusb output:
Then I try this settings in ups.conf :
But when I try upsdrvctl start I get:
So I try to discover more and run ./nutdrv_qx -DDD -a poddasze and get :
So it get some data about voltages , but not enought to start the driver :(
Please help
The text was updated successfully, but these errors were encountered: