NUT package (2.8.0 and below)

tnowak

This post is deleted!

tnowak

@dennypage Solved it by adding user=root in ups.conf section. But this is rather a workaround than a solution. Anyway, this seems to be a problem of nut / file / dev permissions.

dennypage

@tnowak said in NUT package:

Solved it by adding user=root in ups.conf section. But this is rather a workaround than a solution. Anyway, this seems to be a problem of nut / file / dev permissions.

I expect that you are actually in the same situation as the new gen APC listed above: No quirk covering your UPS device (I actually don't see anything from Ever in the table at all).

To confirm, use these steps:

disable nut (Services / UPS / Settings) and save the config
unplug the usb connection to the ups and wait 5 seconds
re-plug the usb connection to the ups
run "usbconfig -d ugen0.2 show_ifdrv"

and post the result. My expectation is that you will see two lines, similar to this:

ugen0.2: <American Power Conversion Smart-UPS1000 FW:UPS 16.0 / ID1047> at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON (10mA)
ugen0.2.0: uhid0: <American Power Conversion Smart-UPS1000 FW:UPS 16.0 / ID1047, class 0/0, rev 2.00/0.01, addr 1>

tman222

Hi @dennypage - thanks again for all your help looking into the signal 10/11 issue with CyberPower UPS units. I'm fine to continue running mine with the interruptonly flag workaround for now even if fewer variables are monitored. After a couple days of running this way, things appear to be stable. If it this setup ends up crashing at some point, I'll probably give the updated usbhid-ups driver a try. Also, if you do end up releasing a nut-devel package at some point that includes fixes post 2.8.0, I'd be happy to try that out as well.

JonathanLee

@dennypage You are amazing I appreciate all you do. Again, thanks for taking the time to look into this issue reported within this discussion. It seems to be a problem with many other users now and you already have a solid solution for it.

tnowak

@dennypage said in NUT package:

@tnowak said in NUT package:

Solved it by adding user=root in ups.conf section. But this is rather a workaround than a solution. Anyway, this seems to be a problem of nut / file / dev permissions.

I expect that you are actually in the same situation as the new gen APC listed above: No quirk covering your UPS device (I actually don't see anything from Ever in the table at all).

To confirm, use these steps:

disable nut (Services / UPS / Settings) and save the config

unplug the usb connection to the ups and wait 5 seconds

re-plug the usb connection to the ups

run "usbconfig -d ugen0.2 show_ifdrv"

and post the result. My expectation is that you will see two lines, similar to this:
ugen0.2: <American Power Conversion Smart-UPS1000 FW:UPS 16.0 / ID1047> at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON (10mA)
ugen0.2.0: uhid0: <American Power Conversion Smart-UPS1000 FW:UPS 16.0 / ID1047, class 0/0, rev 2.00/0.01, addr 1>

Result:

ugen0.2: <EVER ECO PRO AVR CDS> at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON (100mA)
ugen0.2.0: uhid0: <EVER ECO PRO AVR CDS, class 0/0, rev 2.00/1.00, addr 2>

PS. I've also noticed a problem with nut loosing connection to this UPS even with user=root after some time. Then when I restart nut it shows up again.

dennypage

@tnowak said in NUT package:

Result:
ugen0.2: <EVER ECO PRO AVR CDS> at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON (100mA)
ugen0.2.0: uhid0: <EVER ECO PRO AVR CDS, class 0/0, rev 2.00/1.00, addr 2>

PS. I've also noticed a problem with nut loosing connection to this UPS even with user=root after some time. Then when I restart nut it shows up again.

Yep, that shows a kernel driver attached to the device. Same situation as the new series APC devices. Not too surprising, because I don't find any Ever devices defined in the usb table.

You can either use the user=root approach, or you can develop a quirk setting for /boot/loader.conf.local. Based on your prior post, I believe that the correct value would be this:

hw.usb.quirk.0="0x2e51 0x0002 0x0000 0xffff UQ_HID_IGNORE"

You can test this in advance by running this:

usbconfig add_dev_quirk_vplh 0x2e51 0x0002 0x0000 0xffff UQ_HID_IGNORE

followed by unplugging and replugging the usb cable to your ups. If the values are correct, when you run "usbconfig -d ugen0.2 show_ifdrv" again, you should only see one line of output like so:

ugen0.2: <EVER ECO PRO AVR CDS> at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON (100mA)

The ugen0.2.0 should be gone.

If this test works then you can add the line to your /boot/loader.conf.local file.

As to loosing communication after a time, I would still need to see the output from usbhid-ups, either from the system log or from the command line. There seem to be a few issues that do not produce entries in the system log, so I would recommend using the command line as previously discussed.

tnowak

@dennypage said in NUT package:

hw.usb.quirk.0="0x2e51 0x0002 0x0000 0xffff UQ_HID_IGNORE"
You can test this in advance by running this:
usbconfig add_dev_quirk_vlph 0x2e51 0x0002 0x0000 0xffff UQ_HID_IGNORE
followed by unplugging and replugging the usb cable to your ups. If the values are correct, when you run "usbconfig -d ugen0.2 show_ifdrv" again, you should only see one line of output like so:
ugen0.2: <EVER ECO PRO AVR CDS> at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON (100mA)
The ugen0.2.0 should be gone.

Thanks, this was very helpfull. I had to modifiy command a bit, as I've noticed its add_dev_quirk_vplh not vlph and I changed pid (product id) to 0x0000. Now the second line is gone:

Now NUT starts without user=root just fine:

Feb 23 22:27:05	upsmon	20539	Communications with UPS ever established
Feb 23 22:27:05	upsd	23193	User local-monitor@127.0.0.1 logged into UPS [ever]
Feb 23 22:27:01	php	16832	/usr/local/sbin/acbupload.php: End of configuration backup to https://acb.netgate.com/save (success).
Feb 23 22:27:01	upsd	23193	Startup successful
Feb 23 22:27:01	upsd	23193	Connected to UPS [ever]: usbhid-ups-ever
Feb 23 22:27:01	upsd	23193	listening on 127.0.0.1 port 3493
Feb 23 22:27:01	upsd	23193	listening on ::1 port 3493
Feb 23 22:27:00	usbhid-ups	21611	Startup successful

But soon after one minute or so:

Feb 23 22:28:15	upsmon	20539	Poll UPS [ever] failed - Driver not connected
Feb 23 22:28:10	upsmon	20539	Communications with UPS ever lost
Feb 23 22:28:10	upsmon	20539	Poll UPS [ever] failed - Driver not connected
Feb 23 22:28:08	kernel		pid 21611 (usbhid-ups), jid 0, uid 66: exited on signal 10
Feb 23 22:28:08	upsd	23193	Can't connect to UPS [ever] (usbhid-ups-ever): Connection refused

dennypage

@tnowak said in NUT package:

I had to modifiy command a bit, as I've noticed its add_dev_quirk_vplh not vlph

Sorry, typo. I corrected the original post.

But soon after one minute or so:
Feb 23 22:28:08 kernel pid 21611 (usbhid-ups), jid 0, uid 66: exited on signal 10

Congratulations, you are a double winner.
The post above regarding the CyberPower UPS units applies to you as well.

tnowak

@dennypage said in NUT package:

Congratulations, you are a double winner.

Wow, amazing! I deployed that workaround for the time being and it works reliably now! Looking forward for future nut package releases that solves this issue.

You're the man @dennypage! Thank you VERY much for your support that is extremely competent and helpful.

shaffergr

@dennypage

the "usbhid-ups" binary built from the FreeBSD nut-devel port you provided earlier this week to test looks to have solved the problem for me (or at least for those that have CyberPower UPSs). As of this morning eastern time, it's been running for over 72 hours with no more "exit on signal 10" errors in my system log file. Thanks for all your help in identifying the issue and that its already been fixed in the newer version of nut.

JonathanLee

@shaffergr is this available form package manager now?

shaffergr

@jonathanlee

No. Denny provided me a build from nut-devel branch so that we could validate if the signal 10 issue was fix or not.

JPP 0

@dennypage I've been seeing logs like this:

Feb 25 19:37:13 gatekeeper kernel: pid 29800 (usbhid-ups), jid 0, uid 0: exited on signal 10
Feb 25 19:37:15 gatekeeper upsmon[28298]: Poll UPS [tripplite] failed - Driver not connected
Feb 25 19:37:15 gatekeeper upsmon[28298]: Communications with UPS tripplite lost
Feb 25 19:37:20 gatekeeper upsmon[28298]: Poll UPS [tripplite] failed - Driver not connected
Feb 25 19:37:25 gatekeeper upsmon[28298]: Poll UPS [tripplite] failed - Driver not connected
Feb 25 19:37:30 gatekeeper upsmon[28298]: Poll UPS [tripplite] failed - Driver not connected
Feb 25 19:37:35 gatekeeper upsmon[28298]: Poll UPS [tripplite] failed - Driver not connected

<goes on the same until manually restarted.>

setting interruptonly appears to have mitigated it. UPS is a Tripp Lite SMART1500LCD rack mount unit. It seemed to work fine prior to the last update.

dennypage

@jpp-0 I sent you the dev build of usbhid-ups. Please let me know if it works for you.

JPP 0

@dennypage Thanks sending the dev version, it looks to be working, it's been running for over 8 hours with all the extra config (interruptonly and user=root etc) removed. No crashes. It correctly detected power loss and power restored. If it fails laster I'll post and update but I'm not expecting it to as it would fine within minutes before.

wirehead

@dennypage can confirm interruptonly does the job as a workaround with my Cyberpower UPS. Many thanks.

whoami TM

@jpp-0 I couldn't get the Smart1500 LCD I had to work if my life depended on it. I must have had a defective unit. I ended up returning it and getting a APC BGM1500B which worked right out of the box.

I couldn't get offdelay=60 and ondelay=90 to hold. It would hold the settings for 20 mins max then revert to default values.

To top that off the UPS would run down until the battery died and never send shutdown command to my Netgate box.

Can you screen shot or post your settings. I'm interested to find out what actually works with that UPS. I killed myself for weeks until my return window was about to close before my autism would allow me to give up.

link to my orginal post

JPP 0

@whoami-tm right now I just have the defaults set on pfsense. My setup is a bit odd in that it should never get to shutdown becasue the generator / automatic transfer kicks in after 25 seconds and I have about a week's worth of propane on site.

I have by proxmox servers (the very originally named pxoxie and moxie, both nut clients) set to shutdown after 10 mins if for some reason the generator fails.

The pfsense box is not configured to shutdown. I'm running ram disk filesystems so I'm less worried about disk corruption and want to keep it running as long as possible.

I blew away all the config I had on pfSense trying to debug the crashes, I may add some complexity back but not for a while.

Lastly I would not buy Tripplite again it completely fails to give a decent runtime estimate (best guess is the power factor on modife sine wave is different enough from tru sine on the grid that it just get's confused).

JPP 0

This post is deleted!