-
-
Notifications
You must be signed in to change notification settings - Fork 351
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Incorrect data from the **riello_usb** driver #1895
Comments
I wonder if it is a similar issue to that discussed in https://alioth-lists.debian.net/pipermail/nut-upsdev/2017-November/007358.html or #530 in some way?
So at least the two numbers seem "related" (same lower word). Might be a firmware bug or otherwise unexpected behavior (e.g. new protocol?) CC @mzampieri70 @CentroricercheRPS PS: @shgubar Following issues #1744 and #1754, am I correct to assume you are running recent NUT (custom-built from master-branch codebase this year), so possible deficiencies in older distro-packaged code should not be a lead to investigate here? |
I'm not sure if this is exactly the same problem. Because I have already done what is described in the given example, but the result is the same.
Yes, almost everything is true. I used the last master-branch when discussing the problem in the ticket #1858 but still there is a problem. |
By the way, given that you mentioned two devices and only one of them with the problem - can you please post For example, stop the regularly running driver services and instead run Also from the above I understand that both of your devices see correct info after startup, but one becomes wrong after some time? Maybe some bitmask maths vs. int sizes misfired (fixed some bug about those on master in the summer BTW, but I think there the wrong effect was instant). In any case, the number of the Since you build from source, feel free to add more And one more thing, about what I noted earlier, that these numbers seem related in binary representation - on the "physical meaning" side they describe current (Amps) and power (Watts) so should not be intertwined like this... |
These are very good ideas for further analysis of the problem device itself. Thank you. |
Hi, @jimklimov
So, version 1.1 worked for a long time with only the error I pointed out when creating this issue. In version 1.2 when working only with the UPS driver (
These errors were constant. Although when both drivers were working, these errors were from
and it also applied to the output voltage (reached a value of 15580.8), and the battery charge (a value of 11223), etc. Regarding point 3 - the same behavior as in option 1, but something has been added in the logs:
You can also periodically observe the following in the log:
The only plus in the latest version is that NUT does not get hung up on the constant "Poll UPS [rps1000@localhost] failed - Data stale", but establishes a correct connection after several iterations. Next, I provide the logs of the driver for both
After such a number of iterations, I did not notice erroneous data, perhaps it should be increased. I am sure that the problem is the incorrect reading of data from the By the way: for the entire time of testing, I changed 2 different USB cables, USB ports (USB 2.0 and USB 3.0) for |
Then the logs (syslog) as soon as
|
The next start of nut.target shows that some data is missing on the For
For
And log file with parameter |
Thank you for these details. I've tried to contact the original driver authors, but it has been a decade, so not sure what would come of it... Note for future readers: log files seem to have been "escaped" by the syslog server for non ASCII-readable characters, so in text |
@shgubar: Just in case: does it misbehave similarly when only one UPS is physically plugged in, to rule out some cross-talk (if e.g. libusb also gets confused)? |
If disabled UPD: I didn't test the only |
Yes, my suspicion is that maybe somehow reports from two similar USB devices are round-robined by the USB stack, outside of NUT? So the idea to double-check is with only one device physically plugged, ruling out possibility of such confusions completely. Also, given that firmware revisions are different, maybe one is just buggy? :D |
Yeah, maybe. I'll check it out. |
Physically disabled
And
For now, I will leave it in this state until tomorrow. |
So, your assumption was probably correct. Since yesterday, only one UPS was physically connected to the USB (this is exactly the one that constantly showed incorrect data):
Here are the results I see per day:
But sometimes:
The following parameters are missing:
|
Hello @shgubar the problem of the bad communication could be a weak or not correctly connected earth of the UPS. Regards |
Hello @mzampieri70 I have already used other USB cables. |
@shgubar the bad communication with NUT is due to some wrong bytes that alter the Checksum indeed the complete packet is discarded. |
Understand. I will try replacing the power cable. |
Ok let me know |
What was done:
P.S.: the I am very grateful for all your advice! |
HI,
I have two identical UPS - Riello SEP 1000 ER, they differ only in firmware.
SWM073-01-00
SWM073-01-01
The problem is precisely with the one in which the firmware is
SWM073-01-01
.When the NUT Server starts, it displays the correct data, but after some time (it is different), the following data is displayed:
All other data are displayed correctly on both UPS.
By the way, there are no problems with a UPS with
SWM073-01-00
firmware (only with the exception of the serial number - does not show).Please help fix this?
Maybe need to provide some more data to analyze this problem?
Thanks.
The text was updated successfully, but these errors were encountered: