@dennypage Many thanks. I appreciate your knowledge and patience. I now only have NUT running on pfSense. It would be nice if pfSense made a nice-looking widget for NUT, but that's a discussion for another time. Again, thanks for the education.

@dennypage said in 24.03 and Eaton Ellipse Eco 650:

Reboot the firewall.
Add "pollonly" to the "Extra Arguments to driver" section.
Add "user=root" to the "Extra Arguments to driver" section.

Thank you for looking at this. No joy on any of those 3 options, so I will wait patiently for the updated package to materialise.

@dennypage does this help?
ups troubleshooting.txt

@pfsjap said in Netgate 1100 with 24.03-RC and APC Smart-UPS 1000:

Since I didn't add the quirk, it did come with nut package, right?

Quirks in FreeBSD are part of the kernel itself. NUT distributes a bunch of quirks, but they are not used in FreeBSD.

I'm glad that it works following reboot. However, this leaves me without any way to explain why it didn't work originally. 😕

@Unoptanio

For the "Out Voltage" to display a value the UPS must return the value "OUTPUTV" - you will notice that your status, like mine, does not return this value when the device is queried.

Simply it can not display data it does not have available - so you get "N/A"

@mcury said in Ts Shara UPS Xpro Senoidal 2000 Universal 2BS 9AH:

Tried local USB and local serial, both are able to connect to the UPS..
Q1 is not answered, or gets shorts reply.
Same goes for QGS, QS, HW, WH, and all other questions NUT does to the UPS.

Did you try usbhid-ups? This should always be the first driver to try with a USB based UPS. If you haven't already:

In Services / UPS / Settings, change the UPS Type to "Disabled" and save. Disconnect the USB cable. Wait a few seconds Reconnect the USB cable. In Services / UPS / Settings, change the UPS Type to "Local USB", and the Driver to "usbhid" and save.

Going back to qx, if Q1 is not answered then qx isn't the right driver. However... the qx UPSs can have protocol state problems. You have to disconnect/reconnect the USB cable when you change the driver, subdriver or protocol.

If it actually is a qx UPS, I would recommend starting with this:

subdriver = "phoenix"

See this topic for an extensive exploration of qx.

If you post debug output, I might be able to help more.

@dennypage said in NUT Package (2.8.1 and above):

@LanterIT NUT issue #2325.

The fix for accessing battery_voltage_reports_one_pack has been merged, and I expect it to be included in nut-devel snapshot.

I was hoping that the flag would simply be deleted, but the NUT maintainer seemed resistant to that. You will need to maintain the flag in your Extra Augments to driver section.

@keyser said in NUT 2.8.1 when?:

@Gertjan Regardless what I do I cannot get usbdump to output any data. Even “usbdump -v” with no specifics does not output anything.

I think a slight mistake. The output that shown for "usbconfig dump_stats" is actually the output for "usbconfig" (without dump_stats).

FWIW, since you are able re-connect almost immediately to the ups, I don't believe that you will be able to effectively capture the output of usbconfig by hand at the appropriate moment to provide meaningful information. And if you did, I suspect that it would boil down to "there is no usb ups device."

The command usbdump is a slightly different thing. This is something that you would want running before, and during, the time when the disconnect actually happens. Not sure that this is worth the effort though as the most likely outcome is again "there is no usb ups device."

You can certainly run usbdump, but it would probably be more productive to run the driver in debug mode (see later posts in the main 2.8.1 thread for examples). However based upon what you have posted, the most likely outcome is again "there is no usb ups device."

You might want to explore the Advanced section items I suggested a few posts above.

@anthonys

Thanks all.

@markster Please see discussions in the NUT support thread.

@dennypage

Hello - I feel really thick now I've worked out what you meant! For anyone else as stupid as me, you need to do the following:

Download the 2 files upsmon and usbhid-ups which Dennypage has on the other thread circa post #104 - they download as .gz files which are compressed (like .zip, .rar etc)

In my case I was using a windows machine so I extracted them using Winrar and then copied them onto my pfSense machine - I'm sure there's a way to extract them in Linux etc but I'm not great at Linux!

STOP the UPS service in pfSense

I backed up the two existing files in their current directories (/usr/local/sbin/upsmon and /usr/local/libexec/nut/usbhid-ups) by adding .org as a suffix to their name then moved the new files into the directory

The permissions were wrong by default so both files need to be chmod 755 before the service can be started as per the last posts on the thread

You should see the following when you're done if you run the command: ls -l /usr/local/sbin/upsmon* /usr/local/libexec/nut/usbhid-ups*

-rwxr-xr-x 1 root wheel 333728 Jan 15 15:37 /usr/local/libexec/nut/usbhid-ups
-rwxr-xr-x 1 root wheel 287088 Nov 17 13:41 /usr/local/libexec/nut/usbhid-ups.org
-rwxr-xr-x 1 root wheel 87760 Jan 15 15:37 /usr/local/sbin/upsmon
-rwxr-xr-x 1 root wheel 68888 Nov 17 13:41 /usr/local/sbin/upsmon.org

After this it was just a case of restarting the nut service and it started perfectly.

I am guessing that pfSense will release a new version of these files in the coming weeks / months which will remove the need to do this, but in the mean time, I believe the above seems to fix the issue!

Thanks so much to @dennypage for his patience and support with this issue - I'm still learning all this stuff! 😁

@hspindel See the pfSense NUT support thread.

@RyanM said in Downgrade NUT package vs. remote upgrade of pfSense CE:

Just wasn't sure if there was an easy way to "downgrade" NUT.

You could go into the old NUT support thread and grab one of the testing builds that was done earlier in the year. If you do, make sure you get the right arch... the amd64 version was in the February timeframe, and the arm version was a couple of months later.

@dennypage

Good morning,
I updated to pfsense 2.7.1 with Nut ver 2.8.2

The quirk is always inserted in the boot loader.
hw.usb.quirk.0="0x04b4 0x5500 0x0000 0xffff UQ_HID_IGNORE"

I confirm that the Riello VST1100 UPS is working well without disconnection of the USB port

Soon I will also let you know for the "Riello Sentinel Pro 2200" and "Riello Sentinel Dual SDU 6Kw" models

Yesterday (Wednesday 29th November 2023) I upgraded my pfSense router
from v2.7.0-RELEASE and 'nut' version 2.8.0_2
to v2.7.1-RELEASE with 'nut' version 2.8.2

Now after 24 hours of normal usage, and having done a couple of test mains power breaks,
all the issues I was previously having with the intermittent USB monitoring of my Eaton-3S-550 UPS, and associated missing notification emails, appear to have been resolved.

@JHanko

Great,

Now that I had some more time, was going to create a redmine for this issue

and of course discovered there is one that has a similar proposed fixed. So I'm not going to create an account on redmine for the sole purpose of updating it.

https://redmine.pfsense.org/issues/14398

perhaps we could kindly ask @stephenw10 to update the redmine for you (us) so that at some point down the road it ends up in the system.
The redmine indicates affected version is 23.01 (and certainly it is) it is still there for 23.09 and 2.7.1 CE

Thanks

@hspindel Excellent. Thank you for helping test.

Beginning with 2.8.1, I am transitioning NUT support to a new thread, which can be found here.

Please continue to post issues related to 2.8.0_2 and below to this thread.

Also, I am actively seeking people to test the new 2.8.1 pfSense NUT package prior to general release. I would appreciate any help you can offer. Thanks!