UPS equipment offline due to unknown reasons #2599
Comments
|
How is the device configured? The bus/device/port numbers indeed do depend on enumeration, so if the OS decided to change it (bus reset, something plugged/unplugged) we may be out of luck with fixed numbers. Do you have those options in ups.conf? Another idea is that this UPS controller chip may be going to sleep - increasing the polling frequency might help. This ID looks APC, but as they bought out a lot of companies, OEMs under the brand may differ in quality and ability. Which model is that, which country? |
jimklimov
added
bug
APC
USB
Connection stability issues
|
I think Can you please run the driver with higher verbosity, and post more debug context around such events? https://github.com/networkupstools/nut/wiki/Changing-NUT-daemon-debug-verbosity Recent APC BX...MI models were also implicated in some unruly behavior that seems like calibration, issuing many scary reports, recently addressed on NUT master branch. But those cases did not report connection losses... |
|
Thank you for your response. My UPS model is APC BK650M2-CH The current polling frequency is set to 5 seconds |
I have recorded the logs in the way you described, and the partial logs after reconnection are as follows. I am not sure if it is helpful to you. If missing log information is needed, I will supplement it when the loss occurs,About ten hours later. Thanks again |
|
Also, provide my compilation parameters to see if there are any issues |
|
This is the log from the time of the loss of contact |
|
This is a log that has just returned to normal |
|
Thanks! So here it apparently did match the device-reported identification the first time around, but failed to read it during a reconnection attempt (which it did diligently start too, good). As a result, the "newly" located device lacked an "iManufacturer" string (NULL) to match the requested "Vendor" option ("American Power Conversion") in your config, so the device was not accepted as a match during reconnection. As a quick fix, not matching by these strings (vendor, product, serial) where they can not be reliably read can help - if that is the only piece info that is not available. Try to comment those config lines away. In practice, the bigger question is why it is not available - e.g. if the driver's hold on the device did not let the kernel/libusb re-read those strings, or if reconnection logic did not take some steps that the driver stop and initial connection does (e.g. fully close the device, let kernel report on it, then if it matches - take it from kernel), that I can not quickly say. Given that your device later returned to be seen, maybe just its controller was restarting and was really not responsive for some time?.. But this part sounds reminiscent of an ongoing discussion in libusb/libusb#1548 and #2571 / #1925 and maybe your situation would provide clues to re-producing or understanding that problem?.. :) |
No, if the USB cable is not unplugged, it will keep reporting errors, at least for now. Additionally, I did not encounter this issue with 2.8.0 installed from apt, as it continuously reported the "OL+DISCHRG" status. It was only after compiling that I updated it to 2.8.2. Of course, this is another problem I have tried to comment out these fields, and if there are any new developments, I will continue to report. Thank you for your guidance. |
|
For an APC config, try setting onlinedischarge_calibration |
version:2.8.2
sataus:The device will go offline after a period of time, causing the driver to be unable to find the UPS device. Re plugging and unplugging the USB cable will allow the device to be found again
Suspected to be caused by the automatic change of Bus 003 Device 007: ID 051d: 0002. Is there any way to avoid this problem
The text was updated successfully, but these errors were encountered: