Ups Salicru Soho+ (libusb_get_interrupt error on Raspberry pi 3B+)

[kitopopo]

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:

Jun 14 09:28:22 raspberrypi usbhid-ups[447]: libusb_get_string: could not claim 
interface 0: Device or resource busy
Jun 14 09:28:57 raspberrypi usbhid-ups[447]: libusb_get_interrupt: could not cla
im interface 0: Device or resource busy
Jun 14 09:29:32 raspberrypi usbhid-ups[447]: libusb_get_interrupt: error sending
control message: Broken pipe
Jun 14 09:30:07 raspberrypi usbhid-ups[447]: libusb_get_interrupt: error sending
control message: Broken pipe..._

......................

> 
> ```
> 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 from "10" to "60" but the problem does not disappear. 
Also if the pollinterval is too high i can't see shorts energy cuts. 

After the appearance of this error I do not receive any email notification about the loss of communication and I have to go looking at the syslog every day to know if NUT is working correctly.

The error is solved by restarting the raspberry or disconnecting the usb from my Ups and reconnecting it. 

I have also read in a github post that you can increase the time from 250ms to 750ms inside the libhid.c file, but this file can not be found in my raspberry, (https://github.com/zykh/nut/commit/7050d765bf4543024289f02580b352d3d8752372#diff-586626c81aafc6d207e4869a25d57876) . Maybe it will refer to the operating system debian not raspbian. 

I have been trying to solve this error for more than 1 month but I do not know what else to follow and i don't found more information.

I do not know if it would be related to my initial problem, but when starting nut-server I always get this message but all works correctly for a few days:

> jun 15 01:01:00 raspberrypi upsd[498]: Data for UPS [salicru] is stale - check 
> jun 15 01:01:00 raspberrypi upsd[498]: UPS [salicru] data is no longer stale_

I copy my configuration files  in case they can help to solve the problem:

**nut.conf:**
MODE=standalone

**ups.conf**
[salicru]
driver=usbhid-ups
port=auto
desc="SAI Salicru"
pollinterval=35

**upsd.conf**
MAXAGE 25
MAXCONN 1024
LISTEN 127.0.0.1 3493
LISTEN ::1 3493

**upsd.users**
[upsmaster]
  password = secret
  allowfrom = localhost
  upsmon master

[upremote]
  password = secret
  upsmon slave

**upsmon.conf**
#DEADTIME 25
#MAXAGE 25
#POLLFREQ 5
MONITOR salicru@localhost 1 upsmaster secret master
NOTIFYCMD /usr/local/ups/bin/notifyme.sh
NOTIFYMSG ONLINE        "UPS %s on line power"
NOTIFYMSG ONBATT        "UPS %s on battery"
NOTIFYMSG LOWBATT       "UPS %s battery is low"
NOTIFYMSG FSD           "UPS %s: forced shutdown in progress"
NOTIFYMSG COMMOK        "Communications with UPS %s established"
NOTIFYMSG COMMBAD       "Communications with UPS %s lost"
NOTIFYMSG SHUTDOWN      "Auto logout and shutdown proceeding"
NOTIFYMSG REPLBATT      "UPS %s battery needs to be replaced"
NOTIFYMSG NOCOMM        "UPS %s is unavailable"
NOTIFYMSG NOPARENT      "upsmon parent process died - shutdown impossible"
NOTIFYFLAG ONLINE       SYSLOG+WALL+EXEC
NOTIFYFLAG ONBATT       SYSLOG+WALL+EXEC
NOTIFYFLAG LOWBATT      SYSLOG+WALL+EXEC
NOTIFYFLAG FSD          SYSLOG+WALL+EXEC

**upssched.conf**
CMDSCRIPT /bin/upssched-cmd
PIPEFN /var/run/nut/upssched/upssched.pipe
LOCKFN /var/run/nut/upssched/upssched.lock

AT COMMOK * EXECUTE notify
AT COMMBAD * EXECUTE notify
AT REPLBATT * EXECUTE notify
AT NOCOMM * EXECUTE notify
AT FSD * EXECUTE forced-shutdown
AT NOPARENT * EXECUTE notify
AT SHUTDOWN * EXECUTE notify
AT ONLINE * CANCEL-TIMER shutdown
AT ONLINE * EXECUTE resume
AT ONBATT * START-TIMER shutdown 60000
AT ONBATT * EXECUTE shutdown-warning
AT LOWBATT * START-TIMER shutdown
AT LOWBATT * EXECUTE shutdown-warning

Does anyone know how to fix this error? I would be very grateful because I need constant monitoring of my ups.

thanks to everyone , i wait news.

Best regards

[kitopopo]

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

[kitopopo]

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

[kitopopo]

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

[jimklimov]

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 .

[jimklimov]

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 .

[jimklimov]

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.

[kitopopo]

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

[kitopopo]

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

[kitopopo]

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

[jimklimov]

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 .