UPS Ever Duo II Pro with NUT / Linux

Unless you are running a “Home Edition” of a nuclear reactor by Toshiba you need an UPS for your systems. Here’s another tale about running an UPS with nut under Linux. This time it’s an Ever Duo II Pro [PL]. Full specs for Duo II Pro family are available on the manufacturer’s website – but only in Polish. Note that the non-Pro versions are specified with “no software included” and (as I have heard) are “dumb” UPS-es (again: unconfirmed). The Duo II Pro model is “smart” and reports real data instead of just states via contact-closure.

Overview

The external connections are:

4x IEC 60320 C-13 (PC, female) output socket
non-detachable input cable with Schuko plug
2x phone jack for some kind of protection for the phone line
1x USB type B socket for control

To use this UPS with a standard Schuko equipment you will need to buy/build a cable. I built mine by myself; be extra cautious if you try to build and triple check the wiring and insulation. Or even better – let a qualified electrician do it for you. OK, disclaimer provided 😉 .

Just before doing the actual deal I had a chance to test it for a few minutes with nut by the vendor’s desk. Big thanks here to Arest personnel for that opportunity; not many vendors actually care about Linux geeks and their “issues with hardware”, especially with rarely purchased goods like an UPS.

NUT configuration

Ever Duo II Pro works like a charm with blazer_usb driver (Megatec protocol) and responds to Q1 and F commands, as well as the S command for shutdown (-k invocation works). I didn’t check other commands like T (for tests), Q (beep control), etc. – and used novendor option since the device does not respond to the I command.

Example configuration in ups.conf:

[everd2p]
  driver = blazer_usb
  port = auto
  desc = "Ever DUO II PRO 1kVA"
  novendor
  runtimecal=180,100,240,80,720,50

The runtimecal values (for 1kVA model) have been obtained from tech specs on manufacturer’s website (Polish only) and seem to work just fine and provide quite reliable estimations for battery.charge and battery.runtime.

Everything works pretty well, but there’s a glitch. While testing when the battery was not fully charged I observed the LB flag to work well and the bit in Q1 reply is reported, however when discharging a fully-charged UPS the LB flag was not signalled (the device actually did beep faster on low-battery, but did not set the flag so the driver did not set LB). But there is a workaround for that, provided that the runtimecal is properly set (read the fine manual page: man 8 blazer) – the calculation may change over time as the battery degrades though.

The workaround would be to use additional ups entry in ups.conf with the clone driver:

[everd2p-clone]
  driver = clone
  port = blazer_usb-everd2p
  load.off=load.off
  load.on=load.on
  # faster beeps started at about charge:11 and runtime:200
  mincharge=11
  minruntime=200

This way you would run upsmon over everd2p only, but run both drivers. The clone inherits and reports what it’s parent reports, but is able to raise the FSD to upsd when mincharge/minruntime is reached, and your system may start it’s shutdown sequence. Again, read the fine manual: man 8 clone.

I did not put this setup in production yet though (just plain driver invocations currently), but I expect it to work just as good as my tests reveal. The FSD from clone will be fun to observe, and a thing to fix if it fails (being a custom setup).

Test run – charging

Here’s an 14 hour run of the UPS charging with 8-9% load (reported). Initial values are:

input.voltage “240.7”
input.voltage.fault “0.0”
output.voltage “240.7”
ups.load “9”
input.frequency “49.6”
battery.voltage “24.00”
ups.temperature “25.0”
beeper.status “enabled”
ups.type “offline / line interactive”
ups.status “OL”
input.voltage.nominal “230”
input.current.nominal “4.0”
battery.voltage.nominal “24.0”
input.frequency.nominal “50”
battery.charge “0”

And driver estimations at start:

battery runtime exponent : 1.289
battery runtime nominal : 180.0
battery runtime estimate : 0.0

Fig 1. Charging cycle (14h, 50400 sec, 4 variables)

The estimated (by the driver) battery.runtime and battery.charge reach their maximum values after 12 hours (1800 sec and 100% accordingly). The battery.voltage situation while charging follows:

Fig 2. Charging cycle (14h, 50400 sec, 2 variables)

Top battery.voltage = 27.6V

Test run – discharging

And here’s an 30 minute run of the UPS discharging with 14-16% load (reported). Initial values:

input.voltage “235.5” (dropped ~10 seconds after logging started)
input.voltage.fault “0.0”
output.voltage “235.4”
ups.load “13”
input.frequency “49.6” (ditto)
battery.voltage “27.60”
ups.temperature “25.0”
beeper.status “enabled”
ups.type “offline / line interactive”
ups.status “OL” (switched to OB ~10 seconds after logging started)
input.voltage.nominal “230”
input.current.nominal “4.0”
battery.voltage.nominal “24.0”
input.frequency.nominal “50”
battery.charge “100”

And driver estimations at start:

battery runtime exponent : 1.289
battery runtime nominal : 180.0
battery runtime estimate : 180.0

Fig 3. Discharging cycle (30m, 1800 sec, 4 variables)

A zoom into last 4 minutes follows:

Fig 4. Discharging cycle (last 4m, 4 variables)

The battery.voltage situation in the full cycle:

Fig 5. Discharging cycle (30m, 1800 sec, 2 variables)

And last 4 minutes of battery.voltage:

Fig 6. Discharging cycle (last 4m, 2 variables)

The UPS started to beep fast (low battery, no LB though) about 200 seconds before it died. At that time you may observe a battery voltage drop just a bit below 24V. I have done however a different run with load about 9-10% where the fast beeping (again, no LB) appeared at 24.6V. Because of how batteries work (oh well, physics) the voltage cannot be used alone as an indicator for a low battery condition. Therefore good calculations in the driver (runtimecal parameters to a function of voltage, time, and load) are the only option just in case the LB is not signalled by the device via the communications protocol. Two causes I can think of:

some race condition in the UPS firmware (when queried and going LB at the same time for example); possible workaround – increase driver poll delay
UPS not loaded enough (this model is rated 1kVA)

Here is a log snippet from the clone driver when mincharge/minruntime condition kicked-in:

[...]
1714.045791     send_to_all: SETINFO battery.charge "5"
1714.045819     send_to_all: SETINFO battery.runtime "98"
1716.062312     send_to_all: SETINFO output.voltage "230.4"
1716.062362     send_to_all: SETINFO battery.runtime "95"
1718.045434     send_to_all: SETINFO output.voltage "230.2"
1718.045475     send_to_all: SETINFO ups.load "14"
1718.045580     send_to_all: SETINFO battery.runtime "94"
1720.062283     send_to_all: SETINFO ups.load "13"
1720.062333     send_to_all: SETINFO battery.runtime "91"
1722.045773     send_to_all: SETINFO output.voltage "230.3"
1722.045822     send_to_all: SETINFO battery.runtime "90"
1724.061584     send_to_all: SETINFO battery.runtime "87"
1724.061621     Battery runtime low

It segfaulted afterwards, probably it tried to raise FSD to upsd which was not running as this was a pure invocation of the driver only.

Summary

Ever Duo II Pro seems to be a definitely better option than the Orvaldi I tested before (and returned it afterwards anyway). The Ever was even less expensive (in $). Works well with nut but is missing native charge and runtime information (driver needs to compensate for that loss; many – or all – Megatec-alike UPS-es miss that) but the math works really well with a brand new device (in a ~30 minute run it was <20 seconds wrong). The low-battery signalling is definitely an issue, but can be worked around in a way which is not perfect, but seems to work if the battery is healthy.

And last but not least – a “breaking news” warning: Using commands other than test and shutdown.return may get you in trouble. It seems that while testing the UPS with nut I issued one command too much and currently it is not able to switch to OB state and shuts down immediately with “Shutdown imminent!” and “ALARM OL“. Either this is some hwardware/firmware failure or some arguments to Megatec SxxRyyyy command might have caused that (it is used by load.off, shutdown.stayoff and shutdown.return). I suppose this was shutdown.stayoff (S.5R0000) or load.off (S00R0000), but I am unable to confirm it. Looking forward to explore my warranty options and contacting service. Again – do not play with all the commands unless you know what you are doing.

UPS Orvaldi 1000GE with NUT / Linux (rootprompt.apatsch.net)
UPS Ever Duo II Pro with NUT / Linux – bad idea (rootprompt.apatsch.net)

Marcin's rootprompt blog – /dev/web0