blazer_usb and other cheap usb devices won't always start

[deajan]

Hello,

I have a couple of setups with some cheaper USB controlled UPS with NUT and have sporadic nut-driver startup. Sometimes after a reboot, nut-driver service won't start. I've tried 4 different UPS, all with the same USB interface, being 0665:5161 Cypress Semiconductor USB to Serial

I've traced down the issue manually running blazer_usb driver in different scenarios. If I happen to unplug / replug the UPS, and restart nut-driver, everything works great.

Since I cannot just change all the UPS that don't behave correctly, I've built a "well written" script that resets USB hub for given device, or allows resetting device only, allowing to make sure the device will function.

I've modified the systemd service file nut-driver.service to include the following:

ExecStartPre=/usr/local/bin/usb_reset.py --reset-hub --device 0665:5161

With the above, I am assured that nut-driver will start correctly, since the UPS's USB device is reinitialized just before starting the nut driver.

I am aware that this fix is too specific in order to have it included into NUT sources, but perhaps:

• Is there some documentation where I could do a write up about this problem
• Maybe The ExecStartPre line could be added but commented out, so it's possible to enable it for users that have USB UPSes ?

[jimklimov]

I suppose Wiki can be a good place. NUT docs include a FAQ that could mention this too, and the scripts area often used for systems integration stuff, if you'd go the PR way.

One thing to look out for is that many USB vendors cut corners, so a command to reset one port might recycle the whole hub and cause issues for other devices.

[deajan]

I've actually anticipated that.

My script can list hubs per devices with usb_reset.py --list-hubs --device xxxx:xxxx, so it's easy to know which devices would get reset when resetting a hub. On my test hardware, I was lucky and have one device per hub. On "non lucky" hardware, one must plug the UPS in a way to be "alone" on the hub.

I also have a reset device only command with usb_reset.py --reset-device --device xxxx:xxxx which basically sends a USBDEVFS_RESET signal to the device, but that one works less well (success rate is 3/4, I have no idea why when resetting device before loading blazer_usb driver).

and the scripts area often used for systems integration stuff, if you'd go the PR way.*

I'll be happy to make a PR, but I have no idea where to put the file, and where to make a PR for the documentation. Mind to show me ?

[jimklimov]

I suppose a new subdir under scripts makes sense, with a README there. Might be even without integration to web of Makefiles since it may be quite an OS-dependent hack and not everyone needs it.

But reference from FAQ and a NEWS entry may be in order :)

[deajan]

Hello,

I realized I never made a follow up on this. I'm using (successfully) usb_resetter script for various UPS using blazer_usb since a couple of months now.

Did make the PR #1887, but I don't know where the NEWS entry should go please ?