I hope its ok that I posted this in networking… kind of could be a hardware thing.
(note, I tried using NUT but I couldn’t figure out how to get it to work)
I’m trying to use apcupsd which I installed using PakFire. The service runs but I don’t think it ever establishes connection.
The log file is filled with:
“Communications with UPS lost”
I did find a command lsusb (I think) that listed everything connected to a USB port and I did see my APC SmartUPS. So, can anyone tell me what could be wrong"?
Above config also solved my UPS communication that stooped working after changed the HW & Core update (so I am unsure which of these broke the comm)!
I have to stress that old box worked for 5+ years with the UPS by using these config lines:
UPSTYPE apcsmart
DEVICE /dev/ttyS0
Will somebody explain to me what is the cause for above config no longer working?
Some HW details: and I stress that NEW HW is USB 3.0 while old was USB 2.0
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 002: ID 051d:0002 American Power Conversion Uninterruptible Power Supply
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
And full details:
lsusb -D /dev/bus/usb/003/002
Device: ID 051d:0002 American Power Conversion Uninterruptible Power Supply
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 1.10
bDeviceClass 0 [unknown]
bDeviceSubClass 0 [unknown]
bDeviceProtocol 0
bMaxPacketSize0 8
idVendor 0x051d American Power Conversion
idProduct 0x0002 Uninterruptible Power Supply
bcdDevice 0.06
iManufacturer 3 American Power Conversion
iProduct 1 Back-UPS CS 500 FW:808.q7.I USB FW:q7
iSerial 2 BB0541072054
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 0x0022
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xe0
Self Powered
Remote Wakeup
MaxPower 0mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 3 Human Interface Device
bInterfaceSubClass 0 [unknown]
bInterfaceProtocol 0
iInterface 0
HID Device Descriptor:
bLength 9
bDescriptorType 33
bcdHID 1.10
bCountryCode 33 US
bNumDescriptors 1
bDescriptorType 34 Report
wDescriptorLength 1216
Report Descriptors:
** UNAVAILABLE **
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0006 1x 6 bytes
bInterval 100
Device Status: 0x0001
Self Powered
I think I found the issue: at some point in time APCUPSD addon changed the everything inside /etc/apcups back to its original ((I have edited all files from there to send personalized messages to me) and that was also saved in last backup I restored in the new HW.
I am almost sure that a recent add-on upgrade put back the files - none of them was containing my custom developments.
I guess I need to pay attention to apcupsd add-on upgrades.
Thank you!
I would find that very unlikely. The addon update would have had to be interrupted part way through the update or some other non-normal event occur.
The update process has an uninstall script and an install script run in sequence for an upgrade.
The uninstall script stops the running daemon, then it does an addon backup, ie saving all files in the /etc/apcupsd/ directory for apcupsd.
The install script extracts all the files related to the addon and places them in place. Then a restore of the addon backup is carried out. This would then overwrite anything in the /etc/apcupsd directory with the files you had in place prior to starting the upgrade.
The only way that an upgrade would result in all the original files being in the /etc/apcupsd directory would be if the upgrade process was interrupted after the extract_files command in the apcupsd install script, preventing the install script from carrying out the restore or if, after the backup file had been created it was then deleted or renamed so that the install script would not find the backup file to do the restore.
Edit:-
I also use apcupsd and i update at every CU. I also have customised scripts in the ‘’/etc/apcupsd/‘’ directory and the scripts have never been overwritten.
I see. Not the case for this new Box: the box was installed with CU 186 and then a APCUPSD add-on restore was executed using as apcupsd.ipf (backup) a fresh created backup from old box.
This give me 2 possibilities:
Restore failed!
The backup I just created on old HW did contained standard apcupsd files and not the ones I created/edited back in 2022 - and I checked the on the old box /etc/apcupsd/* and all files in there had modified date June 2024. So around June 2024 something wiped my custom apcupsd files…
No worries - I have many ipfire boxes (All connected to UPS-es and using same custom apcupsd files I created in 2022) so I grabbed those from another box.
You can check the backup that you restored from. Although it has a suffix .ipf it is a standard tar archive and can be viewed or opened with all standard tar archive viewers.
You can then check the files in the ‘’/etc/apcupsd/‘’ directory and even open them to check the contents.
I like to understand how these things happened in case they could happen for more people.
