Closed kitopopo closed 3 years ago
Hello everyone,
In case anyone else has this problem after many tests I have discovered what was the problem that caused the error. Using a shorter usb cable the problem does not appear in 30 days, verified. If I put a longer USB cable again the problem reappears. Verified with this UPS model. Thank you all
dear friends, I have been with the same problem for 2 years. the cable did not solve the problem. my ups keeps disconnecting randomly. now also on my raspberry pi 4. is there any way to update the USBHID-UPS driver or nut in raspbian buster? I see there have been no updates for years, maybe this could fix the problem? any idea what is happening?
I've been modifying all the parameters in the configuration files for about two years, but nothing seems to solve the problem. thanks in advance
Dear friends,, i need help. every day a get the same error, this is the log from today:
Mar 28 21:07:09 raspberrypi kernel: [69242.731764] usb 1-1.4.1: USB disconnect, device number 7 Mar 28 21:07:18 raspberrypi usbhid-ups[643]: libusb_get_interrupt: error submitting URB: No such device Mar 28 21:07:28 raspberrypi upsd[649]: Data for UPS [salicru] is stale - check driver Mar 28 21:07:29 raspberrypi upsmon[657]: Poll UPS [salicru@195.x.x.x failed - Data stale
When I get that error the only solution is to reconnect the usb device physically or reset my raspberry, any ideas or solutions? thanks in advance
Well there is not much that NUT can do about OS (power-saving?) or vendor chips cutting corners (not handling a reset call), if any of those are culprits. There may be a chance that libusb-1.0 (currently experimentable from applying to master one of branches that competing PRs are open from) incorporates some retries. But if kernel says there is no device... then not sure if the newer library can do much either.
On Sun, Mar 28, 2021, 23:16 kitopopo @.***> wrote:
Dear friends,, i need help. every day a get the same error, this is the log from today:
Mar 28 21:07:09 raspberrypi kernel: [69242.731764] usb 1-1.4.1: USB disconnect, device number 7 Mar 28 21:07:18 raspberrypi usbhid-ups[643]: libusb_get_interrupt: error submitting URB: No such device Mar 28 21:07:28 raspberrypi upsd[649]: Data for UPS [salicru] is stale - check driver Mar 28 21:07:29 raspberrypi upsmon[657]: Poll UPS @.*** failed - Data stale
When I get that error the only solution is to reconnect the usb device physically or reset my raspberry, any ideas or solutions? thanks in advance
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/networkupstools/nut/issues/703#issuecomment-808960684, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAMPTFG3IZLDQFBXVSOR4UTTF6TCDANCNFSM4HYN645A .
For the original post I see a "value too large for defined type" and a USB message len=256. I can suppose a byte-sized item (255 max) and so maybe a 32-bit OS, might collide poorly? Would @clepple perhaps suggest something specific?..
On Sun, Jun 23, 2019, 00:00 kitopopo @.***> wrote:
Hi,
Today again the same errors, i can read in the log :
Jun 22 22:41:39 raspberrypi kernel: usb 1-1.3: usbfs: USBDEVFS_CONTROL failed cmd usbhid-ups rqt 128 rq 6 len 255 ret -75 Jun 22 22:41:44 raspberrypi usbhid-ups[544]: libusb_get_interrupt: error sending control message: Value too large for defined data type Jun 22 22:41:49 raspberrypi usbhid-ups[544]: libusb_get_interrupt: error sending control message: Broken pipe Jun 22 22:41:54 raspberrypi usbhid-ups[544]: libusb_get_interrupt: error sending control message: Broken pipe Jun 22 22:41:59 raspberrypi usbhid-ups[544]: libusb_get_interrupt: error sending control message: Broken pipe Jun 22 22:42:04 raspberrypi usbhid-ups[544]: libusb_get_interrupt: error sending control message: Broken pipe
In the following link --> https://networkupstools.org/docs/man/usbhid-ups.html appears write:
Repetitive timeout and staleness:
_Some models tends to be unresponsive with the default polling frequency. The result is that your system log will have lots of messages like:
usb 2-1: control timeout on ep0in usb 2-1: usbfs: USBDEVFSCONTROL failed cmd usbhid-ups rqt 128 rq 6 len 256 ret -110 In this case, simply modify the general parameter "pollinterval" to a higher value (like 10 for 10 seconds). This should solve the issue.
I have increased the pollinterval value to "60" but the problem does not disappear. Any ideas to solve the problem? Does anyone know the email address of networkupstools to get in touch with them?
Thanks in advance
Thanks
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/networkupstools/nut/issues/703?email_source=notifications&email_token=AAMPTFCLI6CW3ICTQY77EFLP32OJLA5CNFSM4HYN645KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODYKSD2I#issuecomment-504701417, or mute the thread https://github.com/notifications/unsubscribe-auth/AAMPTFAALUIGPNKWHK3TQQDP32OJLANCNFSM4HYN645A .
By the way, when the device next disappears, can you check if issuing a software reset command to the chip(s) involved would bring it back? See e.g. https://askubuntu.com/questions/645/how-do-you-reset-a-usb-device-from-the-command-line or https://superuser.com/questions/176319/hard-reset-usb-in-ubuntu-10-04 ; the sample program they refer to seems to have nested in GitHub at https://github.com/jkulesza/usbreset
Alternately there are scripts to unbind+bind a device like at http://billauer.co.il/blog/2013/02/usb-reset-ehci-uhci-linux/
I am not sure if it would be okay for NUT generally to do this (as it may have no idea what other devices live off USB hub(s) along the path, and whether those hubs honestly implement a port-reset or chaply reset the whole chip) but I think at some point the possibility of such option was discussed (e.g. have a way in NUT for users to do at their own risk, or document how to set up the OS to do so beside NUT). It may have stalled due to little evidence from the field if that actually helps.
Dear @jimklimov , thanks for your answer.
The next time that the device was disconnected i will inform you, today works fine at the moment and it is very strange since it usually fails me every day.Thanks in advanced. Best regards
hello dear friends,
I have not been able to reset the port in any way, the only way to recover the connection with the ups is to disconnect it physically. I've been looking at possible solutions using udev rules, but since I can't quite understand how udev rules work, I can't adapt it to my raspberry. Could this be a solution? Can you help me to adapt it correctly to be able to test it? Below I put 3 examples
_this rule seems to do something but it gives exit error code = 1 due it can't run upsdrvctl stop or start. anyway these 2 commands do not recover my ups but the udev rule is thrown_
# /etc/udev/rules.d/62-nut-usbups.rules
SUBSYSTEM!="usb", GOTO="nut-usbups_rules_end"
# TrippLite
# e.g. TrippLite SMART1500LCD - usbhid-ups
ACTION=="add|change", SUBSYSTEM=="usb|usb_device", SUBSYSTEMS=="usb|usb_device", ATTR{idVendor}=="09ae", ATTR{idProduct}=="2012", MODE="664", GROUP="nut", RUN+="/sbin/upsdrvctl stop; /sbin/upsdrvctl start"
LABEL="nut-usbups_rules_end"
_This rule doesn't works with symbols - or + , I have also tried to remove these symbols but it does not seem to work_
@@ -1,7 +1,10 @@
# udev rules for the NUT USB drivers
-SUBSYSTEM!="usb_device", GOTO="nut-usbups_rules_end"
ACTION!="add", GOTO="nut-usbups_rules_end"
+ENV{DEVTYPE}=="usb_device", GOTO="nut-usbups_rules_no-device-class"
+SUBSYSTEM!="usb_device", GOTO="nut-usbups_rules_end"
+
+LABEL="nut-usbups_rules_no-device-class"
# MGE UPS SYSTEMS - usbhid-ups
SYSFS{idVendor}=="0463", SYSFS{idProduct}=="ffff", MODE="664", GROUP="nut"
--
This rule works but with error Bus in the log. I try also erase the bus word but doesn't works
For APC UPS BR550I or BR550GI use the ff.
vi /etc/udev/rules.d/52-nut-usbups.rules
# This file is generated and installed by the Network UPS Tools package.
ACTION!="add", GOTO="nut-usbups_rules_end"
SUBSYSTEM=="usb_device", GOTO="nut-usbups_rules_real"
SUBSYSTEM=="usb", GOTO="nut-usbups_rules_real"
BUS!="usb", GOTO="nut-usbups_rules_end"
LABEL="nut-usbups_rules_real"
# APC
# various models - usbhid-ups
ATTR{idVendor}=="051d", ATTR{idProduct}=="0002", MODE="664", GROUP="nut"
LABEL="nut-usbups_rules_end"
can you guys help me create a udev rule that works for raspberry? as I have read NUT generates a udev rule in linux but not in raspberry.
If the solution cannot be done with udev rules, could there be some other way? I have many other usb devices and these do not disconnect in my raspberry, the only device that disconnects is the UPS and I do not understand why this is a linux problem when all other devices such as hard drives and zigbee2mqtt do not disconnect from the usb. I think it could be a driver problem. Don't you have a more updated driver? I look forward to hearing from you,
thanks in advance.
Best regards
Hello everyone and @jimklimov
I have been able to solve the problem but with tools external to NUT, it is a shame that they do not know where the problem is since I have other USB devices connected and these linux devices do not disconnect them over time (zigbee2mqtt for example) .
Next I explain how I have solved it and if someone needs more information, they can request it.
I have bought a usb 2.0 hub with dual outputs (one for PC and one for the raspberry pi). I have connected my ups to this usb hub and one of its outputs to the raspberry pi4. To the hub button I have connected a sonoff 1ch diy relay with tasmota firmware for can be detected and added the relay in domoticz to be able to switch the hub remotely through domoticz. I have installed domoticz's existing NUT plugin for domoticz. I have made a simple script in domoticz with dzvents that does the following: When we have a communication error with the UPS, salicru switches the hub, after 3 seconds it switches the hub again and the UPS enters communications again. I have also added to the domoticz script a corresponding silenced notification to a telegram bot to keep track of when the UPS produces random disconnections.
With all this process what I do is a physical disconnection of the UPS in the raspberry. I hope someone can be useful, I have not been able to find more solutions. I've been watching it for 2 weeks and it works great. Wonderful Domoticz, thanks @gizmocuz.
I am more and more surprised every day. a cordial greeting
Best regards and thanks
Reminds me of a watchdog to reset a system, based on a depleting capacitor wired to the HDD LED, and to reset pins. No disk activity for unbelievably long? Boom!
At least this got your USB chain reliably reset... it is upsetting when the OS won't tell the device to reset, or device won't agree or do it automatically by detecting a loss without unplug... For fairness, same things happen in storage with some backplanes connecting dozens of disks to an HBA - some models and vendors perform better and more reliably than others...
On Tue, Apr 27, 2021, 22:28 kitopopo @.***> wrote:
Closed #703 https://github.com/networkupstools/nut/issues/703.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/networkupstools/nut/issues/703#event-4653022584, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAMPTFCQI73PBQKBFQ57N73TK4M6JANCNFSM4HYN645A .
Hello,
I need some help. Install NUT for months on a Raspberry with Raspbian. I have a UPS Salicru Soho + and I am using the USBHID-UPS driver. Everything works fine for 1 or 2 days, but on the third day I get the following error in the syslog:
Repetitive timeout and staleness:
_Some models tends to be unresponsive with the default polling frequency. The result is that your system log will have lots of messages like:
usb 2-1: control timeout on ep0in usb 2-1: usbfs: USBDEVFSCONTROL failed cmd usbhid-ups rqt 128 rq 6 len 256 ret -110 In this case, simply modify the general parameter "pollinterval" to a higher value (like 10 for 10 seconds). This should solve the issue