Communication issues with TrippLiteSU1000RTXLCD2U

dennypage

Should I remove user=root from the Additional configuration lines for ups.conf now that I added the quirk?

Is it best practice to have the UPS plugged into USB bus 0? I had it plugged into bus 1 for years, but recent lost connections with the UPS after upgrading to pfSense 2.7 prompted me to make these changes in hopes of reliability.

Sorry, I missed these.

Yes, you should remove the user=root from the Additional configuration lines for ups.conf section. NB: user=root can now be put into the Extra Arguments to driver section instead.

The bus number doesn't matter, however the USB driver chips may. If you have a problem with one USB interface, it's always a good idea to try the other.

serengeti

@dennypage I made the above changes 3 weeks ago and haven't touched it since.

Most days, about once or twice per day, I'm still seeing the following notifications in the space of a minute:

Communications with
UPS TrippLiteSU1000RTXLCD2U lost

Communications with
UPS TrippLiteSU1000RTXLCD2U unavailable

Communications with
UPS TrippLiteSU1000RTXLCD2U established

I don't know why this is happening, what the consequences are, or where to file a bug (in NUT?, pfSense? FreeBSD? USBhid?)?

Regarding the USB bus, I think its safe to assume that the Dell R210 has one USB chipset (no USB PCI cards are installed, so trying different buses wouldn't solve this ...usbus0, usbus1, etc.).

It might help if these notifications were more verbose about the cause of the problem? –e.g.,

Communications with
UPS TrippLiteSU1000RTXLCD2U lost due to crash of usbhid driver (error code 1234).

dennypage

@serengeti said in Communication issues with TrippLiteSU1000RTXLCD2U:

I think its safe to assume that the Dell R210 has one USB chipset

FWIW, you can check this with "usbconfig -v"

@serengeti said in Communication issues with TrippLiteSU1000RTXLCD2U:

It might help if these notifications were more verbose about the cause of the problem?

The usbhid driver isn't crashing. If it were, it would not recover. To try to get more information about why the disconnect happens, you can run the driver in debug mode. See Running NUT drivers with debugging for information.