UPS found, but does not show any data or alert

TrueNAS General
,
1

I’m trying to setup my UPS, an EATON 3S 850 supported by the driver usbhid-ups, to be monitored by TrueNAS.
I previously ran Unraid with the same setup, and had no problem with it.

I first reied setting it up from the UI, and it seemed to work. This is the setup:

image
image754×473 19.8 KB

The UPS seems to be recognised (I initially get an alarm of missing communication, which then goes away), but reporting is all empty:

image
image979×444 5.36 KB

Also, I tried unplugging the power and TrueNAS did not relay any alarm as Unraid did.

I tried to do some more digging from the CLI.

This is the output ot nut-scanner:

# nut-scanner -U -N
Scanning USB bus.
[nutdev1]
        driver = "usbhid-ups"
        port = "auto"
        vendorid = "0463"
        productid = "FFFF"
        product = "Eaton 3S"
        serial = "Blank"
        vendor = "EATON"
        bus = "003"

As you can see, everything good. I wrote these values to /etc/nut/ups.conf, just in case. However, I still get:

# upsdrvctl start
Network UPS Tools - UPS driver controller 2.8.0
Network UPS Tools - Generic HID driver 0.47 (2.8.0)
USB communication driver (libusb 1.0) 0.43
Can't claim USB device [0463:ffff]@0/0: Entity not found
Driver failed to start (exit status=1)

The Arch wiki claims this to be a permission problem, but even setting the UDEV rule did not solve it.

Running upsdrvsvcctl start returns:

=== The currently defined service units are:
Starting nut-driver@EATON-3S-850.service ...
Job for nut-driver@EATON-3S-850.service failed because the control process exited with error code.
See "systemctl status nut-driver@EATON-3S-850.service" and "journalctl -xeu nut-driver@EATON-3S-850.service" for details.

The systemd Journal contains:

Dec 01 12:26:16 giuseppi systemd[1]: nut-driver@EATON-3S-850.service: Scheduled restart job, restart counter is at 98.
░░ Subject: Automatic restarting of a unit has been scheduled
░░ Defined-By: systemd
░░ Support: https://www.debian.org/support
░░
░░ Automatic restarting of the unit nut-driver@EATON-3S-850.service has been scheduled, as the result for
░░ the configured Restart= setting for the unit.
Dec 01 12:26:16 giuseppi systemd[1]: Stopped nut-driver@EATON-3S-850.service - Network UPS Tools - device driver for NUT device 'EATON-3S-850'.
░░ Subject: A stop job for unit nut-driver@EATON-3S-850.service has finished
░░ Defined-By: systemd
░░ Support: https://www.debian.org/support
░░
░░ A stop job for unit nut-driver@EATON-3S-850.service has finished.
░░
░░ The job identifier is 625462 and the job result is done.
Dec 01 12:26:16 giuseppi systemd[1]: Starting nut-driver@EATON-3S-850.service - Network UPS Tools - device driver for NUT device 'EATON-3S-850'...
░░ Subject: A start job for unit nut-driver@EATON-3S-850.service has begun execution
░░ Defined-By: systemd
░░ Support: https://www.debian.org/support
░░
░░ A start job for unit nut-driver@EATON-3S-850.service has begun execution.
░░
░░ The job identifier is 625462.
Dec 01 12:26:16 giuseppi nut-driver@EATON-3S-850[986042]: Can't claim USB device [0463:ffff]@0/0: Entity not found
Dec 01 12:26:16 giuseppi nut-driver@EATON-3S-850[986042]: Network UPS Tools - Generic HID driver 0.47 (2.8.0)
Dec 01 12:26:16 giuseppi nut-driver@EATON-3S-850[986042]: USB communication driver (libusb 1.0) 0.43
Dec 01 12:26:16 giuseppi nut-driver@EATON-3S-850[986041]: Driver failed to start (exit status=1)
Dec 01 12:26:16 giuseppi nut-driver@EATON-3S-850[986041]: Network UPS Tools - UPS driver controller 2.8.0
Dec 01 12:26:16 giuseppi systemd[1]: nut-driver@EATON-3S-850.service: Control process exited, code=exited, status=1/FAILURE
░░ Subject: Unit process exited
░░ Defined-By: systemd
░░ Support: https://www.debian.org/support
░░
░░ An ExecStart= process belonging to unit nut-driver@EATON-3S-850.service has exited.
░░
░░ The process' exit code is 'exited' and its exit status is 1.
Dec 01 12:26:16 giuseppi systemd[1]: nut-driver@EATON-3S-850.service: Failed with result 'exit-code'.
░░ Subject: Unit failed
░░ Defined-By: systemd
░░ Support: https://www.debian.org/support
░░
░░ The unit nut-driver@EATON-3S-850.service has entered the 'failed' state with result 'exit-code'.
Dec 01 12:26:16 giuseppi systemd[1]: Failed to start nut-driver@EATON-3S-850.service - Network UPS Tools - device driver for NUT device 'EATON-3S-850'.
░░ Subject: A start job for unit nut-driver@EATON-3S-850.service has failed
░░ Defined-By: systemd
░░ Support: https://www.debian.org/support
░░
░░ A start job for unit nut-driver@EATON-3S-850.service has finished with a failure.
░░
░░ The job identifier is 625462 and the job result is failed.

As you can see, no dice. Any idea?

2

Try changing your identifier to “ups”.

1 Like
3

yeah the reporting breaks if you use any identifier then “ups”

4

Thanks for your input. I tried changing the identifier to ups. I got a UPS communication alarm, which autocleared after a while. But still no data, and I get no warnings when the UPS activates.

How can I verify that the UPS integration is working?

5

from shell you can check if communication is working with upsc ups@localhost

6

After a reboot - everything seems to work fine now!

So the ups trick did it. Thanks to both of you!

7

Generally, any services found under System → services should be stopped then restarted after any configuration edits or changes. This is usually enough to get the service to pick up the changes made. It was designed this way I think to avoid taking down the entire server for a simple change in a service.

8

Purchased a Eaton 3S 850 after reading this thread :slight_smile:

It seems to be working but not all the UPS reporting charts are working.

Those that don’t work are:

UPS Voltage - Battery
UPS Voltage - Input
UPS Input Current
UPS Input Frequency
UPS Temperature

root@truenas[~]# upsc ups@localhost
Init SSL without certificate database
battery.charge: 100
battery.charge.low: 20
battery.runtime: 1560
battery.type: PbAc
device.mfr: EATON
device.model: Eaton 3S 850
device.serial: Blank
device.type: ups
driver.name: usbhid-ups
driver.parameter.pollfreq: 30
driver.parameter.pollinterval: 2
driver.parameter.port: auto
driver.parameter.synchronous: auto
driver.version: 2.8.0
driver.version.data: MGE HID 1.46
driver.version.internal: 0.47
driver.version.usb: libusb-1.0.26 (API: 0x1000109)
input.transfer.high: 264
input.transfer.low: 184
outlet.1.desc: PowerShare Outlet 1
outlet.1.id: 1
outlet.1.status: on
outlet.1.switchable: no
outlet.desc: Main Outlet
outlet.id: 0
outlet.switchable: yes
output.frequency.nominal: 50
output.voltage: 230.0
output.voltage.nominal: 230
ups.beeper.status: enabled
ups.delay.shutdown: 20
ups.delay.start: 30
ups.firmware: 02.08.0010
ups.load: 20
ups.mfr: EATON
ups.model: Eaton 3S 850
ups.power.nominal: 850
ups.productid: ffff
ups.realpower: 136
ups.serial: Blank
ups.status: OL
ups.timer.shutdown: -1
ups.timer.start: -1
ups.type: offline / line interactive
ups.vendorid: 0463

Does everything look OK?
9

Same for me, not all charts are working. But the UPS works fine and the system manages to shutdown on low battery, so it does not matter to me.

10

This worked for me!

I didn’t even have to restart the UPS service (although editing the item may have automatically restarted the UPS service).

Procedure:

System>Services click edit icon for the UPS service.

Change General Options: Identifier to “ups” (which was the default)

After this parameter edit, the UPS Report graphs started being populated.

Apparently, the Reporting part of TrueNAS is not picking the Identifier up from the Services part.

11

As a warning to others who might see this thread the Eaton 3S 850 is not a very good UPS.

Mine failed in less than 6 months. As the adage goes buy cheap buy twice. I discovered that the VA rating does not mean much and its the size of the battery that matters. Eaton 3S 850 is basically a glorified surge protector with a tiny battery.

I have replaced the Eaton 3S 850 with an APC SMT750IC which works great in TrueNAS using the same usbhid-ups driver as the Eaton. It does cost 3 times as much, but I think its worth it. Considering it costs less than a high capacity HDD’s these days.

The Eaton failed to gracefully shut down my NAS three weeks ago during a power outage, and once a week after it would shut down for no reason (it might even have been the UPS that caused the RCD to trip).

So the moral of this story is if you are looking for a UPS get one that is a real line‑interactive, pure sine wave, with a large battery, and efficient inverter.

I chose the APC SMT750IC as it had 200+ Positive reviews on Amazon. All the cheaper UPS’s had mixed reviews regarding noise, quality, and performance issues.

12

Interesting - 25.10.1 here, and I just had a look. I get no reports either, identifier is “ups” and service restarted. UPS has been connected for a very long time, and works when power goes out but charts in reporting are empty. I can query from shell with upsc ups@localhost:6547 just fine.

image
image782×499 11.4 KB

Thanks CC

13

Hmm my reporting is working

image
image796×532 13 KB

image
image1678×823 54.3 KB

14

Only thing I can see different is that min runs on port 6547 on localhost…..

15

Yep, TN does not give you any UPS status at all.

Proper implementation would give us a page with the results of “upsc ups”, like pretty much any other appliance/is does (pfsense).

1 Like
16

Pretty sure the TrueNAS Scale reporting side of things ignores port (the default NUT port is 3493) and also has the name “ups" hard coded into the report scripts, so at least the name and port fields are… pointless.

It’s only ever going to work with “ups” and the stock port. :man_shrugging:

1 Like
17

Weirdly NUT is configured to run on port 3511. My reporting is also not working, but I also can’t find an option, where to modify the NUT port? I assume the different port breaks the reporting, as I respected the normal “ups” identifier.

image
image1005×628 15.1 KB

1 Like
18

The solution of using ‘ups’ as the identifier and the default port (3493) doesn’t work for me. The reports are still empty in TN 25.10.3.1 (Goldeye) and have never worked. I’m at a loss as to whether UPS is working or not.

My NUT server is my OPNsense firewall and it has the UPS directly attached via USB. TN is configured as a NUT slave. When I first start the UPS service in TN I see one initial request in firewall logs from TN→OPNsense on port 3493 and this is being redirected to localhost:3494 correctly. From that point on there are no more firewall logs but there is a persistent pf state, which I guess means that TN is maybe using the same source port each time it contacts the NUT server for an update? (Either that, or, it never contacts again and the TCP state is just lingering).

I don’t know if it’s related to the reports issue but for some reason I also have occasional alerts that the UPS connection was lost, although infrequent. There should be a fair amount of UPS data to report even with momentary disconnects, though.

This isn’t adding up. I’d appreciate some pointers.

TrueNAS side:

(OPNsense has the monitor user hard-coded as “monuser” so I have to use that instead of “upsmon”)

ups-config
ups-config641×568 19.9 KB

ups-reports
ups-reports2307×1202 63.4 KB

OPNsense side:

state
state2130×347 33 KB

opensense-nut-status
opensense-nut-status605×1054 60.5 KB

Example TN alert:

[
{
“subject”: “Alerts”,
“html”: “TrueNAS @ truenasCurrent alerts:\nCommunication with UPS ups lost.UPS Statistics: ‘ups’Statistics could not be recovered\n\n”,
“to”: [
“``<redacted>@gmail.com``”
]
}
]

19

For what it’s worth (regarding the issue in my above post), the test fails with @localhost but works with @192.168.1.1 which is my NUT host.

truenas_admin@truenas[~]$ upsc ups
Error: Connection failure: Connection refused
truenas_admin@truenas[~]$ upsc ups@192.168.1.1
Init SSL without certificate database
battery.charge: 100
battery.charge.low: 10
battery.charge.warning: 20
battery.mfr.date: CPS
battery.runtime: 1325
battery.runtime.low: 480
battery.status: 100%
battery.type: PbAcid
battery.voltage: 27.6
battery.voltage.nominal: 24
device.mfr: CPS
device.model: CP1500PFCLCDa
device.serial: <redacted>
device.type: ups
driver.debug: 0
driver.flag.allow_killpower: 0
driver.name: usbhid-ups
driver.parameter.interrupt_pipe_no_events_tolerance: -1
driver.parameter.pollfreq: 12
driver.parameter.pollinterval: 2
driver.parameter.port: auto
driver.parameter.synchronous: auto
driver.state: quiet
driver.version: 2.8.3
driver.version.data: CyberPower HID 0.83
driver.version.internal: 0.62
driver.version.usb: libusb-1.0.0 (API: 0x01000102)
input.sensitivity: normal
input.transfer.high: 139
input.transfer.low: 100
input.voltage: 119.0
input.voltage.nominal: 120
output.voltage: 119.0
ups.beeper.status: enabled
ups.delay.shutdown: 60
ups.delay.start: 120
ups.firmware: CR01802CB
ups.load: 35
ups.mfr: CPS
ups.model: CP1500PFCLCDa
ups.power: 346
ups.power.nominal: 1500
ups.productid: 0601
ups.realpower: 353
ups.realpower.nominal: 1000
ups.serial: <redacted>
ups.status: OL
ups.test.result: Done and passed
ups.timer.shutdown: -60
ups.timer.start: -60
ups.vendorid: 0764

When I run it this way I see a unique firewall log each time with a different source port from TN, so does it mean that there is a bug? TN is maybe not monitoring the UPS at all?

20

So your ups is not connected to truenas but a remote host? That would explain why your reporting is not populating, there’s a known bug with remote ups’s not populating the reporting tab…