6.6.0 UPS alerts not sent

---

ewok wrote:

Did you receive similar UPS communication error messages with previous versions of the firmware? 

ewok

Pre 6.6.0 UPS was working normally.

6.6.0 has UPS problems, as documented by me above ~2016-11-14 (System/Power/UPS -> UPS_RAWSTATUS_WAIT)

6.6.1 beta 1, changed but still has a problem, as documented above ~2016-11-18 (System/Power/UPS -> Waiting for status update.)

ReadyNAS does not detect UPS on battery & does not shutdown as it should.

extracts of syslog are in the above posts showing upsc output

@> ewok wrote:

> What is the output of 'upsc UPS'

Welcome to ReadyNASOS 6.6.1-T200 (Beta 1)
root@ME-NAS-316A:~# upsc UPS
Error: Server disconnected

I sent logs as per mdgm-ntgr request 2016-11-19

Note ShoGinn has this issue as posted above, as do bobaloca powellandy1 TOMA1 as posted here (re beta 1)

https://community.netgear.com/t5/ReadyNAS-Beta-Release/ReadyNASOS-6-6-0-RC2-UPS-problems/m-p/1145500#U1145500

Hello,

I have (had?) the same issues (Stale data, UPS_RAWSTATUS_WAIT)  with my RN204 (firmware 6.6.0) with a CyberPower CP1550EPFCLCD UPS (usb connection)

I've changed some parameters in /etc/nut/ups.conf; in particular, following the information found in http://networkupstools.org/docs/man/ups.conf.html and http://networkupstools.org/docs/man/usbhid-ups.html,  I've added:

  synchronous = yes
  pollonly = yes
  pollinterval = 10

And (at least for now) it seems to work fine

---

Michael_Oz wrote:

---

Pre 6.6.0 UPS was working normally.

6.6.0 has UPS problems, as documented by me above ~2016-11-14 (System/Power/UPS -> UPS_RAWSTATUS_WAIT)

6.6.1 beta 1, changed but still has a problem, as documented above ~2016-11-18 (System/Power/UPS -> Waiting for status update.)

ReadyNAS does not detect UPS on battery & does not shutdown as it should.

extracts of syslog are in the above posts showing upsc output

 

@> ewok wrote:

> What is the output of 'upsc UPS'

 

Welcome to ReadyNASOS 6.6.1-T200 (Beta 1)
root@ME-NAS-316A:~# upsc UPS
Error: Server disconnected

 

... uh?! can't edit my previous post...

So it seems that after a reboot /etc/nut/ups.conf gets overwritten/recreated :smileysad: In order to maintain those configuration changes we need to create an alternate configuration file and have the nut daemon use it.

Here's what I did:

Connecting to my NAS using ssh, I edited (using vi) /lib/systemd/system/nut-driver.service to look like this:

[Unit]
Description=Network UPS Tools - power device driver controller
After=local-fs.target network.target systemd-udev-settle.service
Wants=systemd-udev-settle.service
StopWhenUnneeded=yes

[Service]
Environment="NUT_CONFPATH=/etc/nuts"
ExecStart=/sbin/upsdrvctl start
ExecStop=/sbin/upsdrvctl stop
Type=forking

(notice the line starting with Environment right after [Service]: this line changes the path containing configuration files to /etc/nuts)

Next, I created a copy of the /etc/nut directory in /etc/nuts (this way if the original ups.conf file is overwritten we won't care)

cp -r /etc/nut /etc/nuts

Next, I've modified the file /etc/nuts/ups.conf (that's the copy we made in /etc/nuts) and added these two lines (Note: in my previous post I made a mistake since pollinterval is not supported by the usbhid-ups driver):

 synchronous = yes
 pollonly = yes

In my case the resulting file looks like this now:

[UPS]
  driver = usbhid-ups
  port = auto
#dashboard:  ups_model = CP1500EPFCLCD
#dashboard:  ups_mfr = CPS
#dashboard:  ups_mfr_date = 
  serial = XXXXXXXXXXXX
  vendorid = 0764
  synchronous = yes
  pollonly = yes
  productid = 0501

The documentation for the pollonly flag says that "If this flag is set, the driver will ignore interrupts it receives from the UPS (not recommended, but needed if these reports are broken on your UPS). "

For the synchronous flag, the documentation says " The driver work by default in asynchronous mode (i.e synchronous=no). This means that all data are pushed by the driver on the communication socket to upsd (Unix socket on Unix, Named pipe on Windows) without waiting for these data to be actually consumed. With some HW, such as ePDUs, that can produce a lot of data, asynchronous mode may cause some congestion, resulting in the socket to be full, and the driver to appear as not connected."

You can test the configuration by restarting the daemon with:

systemctl daemon-reload
systemctl restart nut-driver

... and check that the daemon is running with:

systemctl status nut-driver

I hope this helps and solves your issues too (... while we wait for an official fix)

Well as we can't reproduce this we would need remote access to a system still having problems after the fix in 6.6.1 Beta.

---

mdgm wrote:

Well as we can't reproduce this we would need remote access to a system still having problems after the fix in 6.6.1 Beta.

---

mdgm-ntgr

I'm game.

Well, to test, I did the ups.conf change to add

  synchronous = yes
  pollonly = yes

Not the whole make a second copy change, I don't reboot often

It has now been over two hours without an error message.

system.log shows below, and no errors.

Dec 01 14:36:31 ME-NAS-316A usbhid-ups[9184]: Startup successful
Dec 01 14:36:33 ME-NAS-316A upsd[6853]: Connected to UPS [UPS]: usbhid-ups-UPS
Dec 01 14:36:40 ME-NAS-316A msmtpq[9199]: mail for [ -C /etc/msmtprc michael...@...com.au --timeout=60 ] : send was successful
Dec 01 14:38:32 ME-NAS-316A upsd[6853]: User monuser@192.168.1.10 logged into UPS [UPS]

The mail was the Comms OK msg.

I unplugged the UPS, it behaved as expected. Got the frontview status changes, emails and the network monitoring of the NV+ too.

So that should do until a fix gets released.

Stll happy for a remote session if someone from NG wants to look around.

Were both of these options needed or does it still fail when only of them are applied?  We can add this fix to the firmware, but need to know if both are required since we can't reproduce it here.

I'll test today.

Hello,

here are some intial test results:

  UPS: Cyberpower CP1500EPFCLCD
 
  WORKING CONFIGURATION

  synchronous = yes
  pollonly = yes
  Tested, stable for 24h
 

  PROBABLY WORKING CONFIGURATION

  pollonly = yes
  In-progress (but seems stable)... will check again in a few hours
   
  NON-WORKING CONFIGURATIONS

  synchronous = yes
  Hangs after a while, and I periodically got the following message in the log: libusb_get_interrupt: Connection timed out
 
  no-additional parameters (default config)
  Logs show libusb_get_interrupt: Connection timed out
  After some time 'upsc UPS' returns Data stale

I'm still testing (needs to do power fail tests), but looks like I will have the same results.

I also tested pollinterval=10, seemed to work, I'll test some other numbers.

Hello again,

for myUPS (Cyberpower CP1500EPFCLCD) the important parameter that needs to be added to ups.conf to fix this issue is pollonly = yes

In summary:

 SUGGESTED WORKING CONFIGURATION
  pollonly = yes
  Tested, stable

  (ALSO) WORKING CONFIGURATION
  synchronous = yes
  pollonly = yes
  Tested, stable

  NON-WORKING CONFIGURATIONS
  synchronous = yes
  Hangs after a while, and I periodically got the following message in the log: libusb_get_interrupt: Connection timed out
 
  no-additional parameters (default config)
  Logs show libusb_get_interrupt: Connection timed out
  After some time 'upsc UPS' returns Data stale

UPS: Cyberpower VALUE1200ELCD

Details from ups.log:

device.mfr: CPS
device.model: Value1200E
device.type: ups
driver.name: usbhid-ups
driver.parameter.pollfreq: 30
driver.parameter.pollinterval: 5
driver.parameter.port: auto
driver.parameter.productid: 0501
driver.parameter.synchronous: no
driver.parameter.vendorid: 0764
driver.version: 2.7.4
driver.version.data CyberPower HID 0.4
driver.version.internal: 0.41
ups.beeper.status: enabled
ups.delay.shutdown: 20
ups.delay.start: 30
ups.load: 32
ups.mfr: CPS
ups.model: Value1200E
ups.productid: 0501

Test a. No errors for > 2 hours, b. correct behaviour when UPS unplugged.

Same, general results as slashdotted, different errors (no timeout error):

Individually:

synchronous=yes - fail

Dec 02 16:45:22 ME-NAS-316A usbhid-ups[25161]: Startup successful
Dec 02 16:45:24 ME-NAS-316A upsd[29633]: Connected to UPS [UPS]: usbhid-ups-UPS
Dec 02 17:25:42 ME-NAS-316A upsd[29633]: Data for UPS [UPS] is stale - check driver
Dec 02 17:25:42 ME-NAS-316A upsmon[29636]: Poll UPS [UPS@localhost] failed - Data stale

pollonly=yes - pass

pollinterval=5 - pass

For me, I think pollinterval=5 would be better as pollonly=yes ignores interrupts, which are apparently working on my UPS.

However if pollonly is easier, hay it works.

BTW, if my reading is correct, the pollfreq=30 has the USB driver wait 30 seconds between polls, listening for interrupts, while pollinterval is the delay between upsd 'updating the status'. Thus pollinterval shorter than pollfreq/2 (ie on average) will only be benificial in upsd picking up interupts prior to the next poll.So, in the bigger picture, a few seconds doesn't matter when power fails, a higher pollinterval may be called for. It only really affects reporting of UPS status, and that is only meaningfull when it is discharging, or less so, when recharging. [question is what types of messages the UPS sends unsolicited, i.e. via interrups?]

So I can't see why a pollinterval<15 is of much use. Even a pollinterval=9, will check for changes ~3 times per poll.

pollonly=yes 'ignore interrupts it receives from the UPS', presumably does not affect pollfreq, but without interrups power notification is delayed, thus the question of whether pollfreq should perhaps be shortened? The above pollinterval considerations apply. So, for example, pollfreq=10 & pollinterval=5, or (15/5, 10/3?) should be considered, and tested.

mdgm-ntgr - L3 have remoted into my 3 NASes over the weekend (under case 27517658)

A

slashdotted

Please try the pollinterval setting as Michael_Oz suggested.  If this works for you, pollinterval is probably the most flexible fix for this since some UPS models may work with a setting of 10, while another may require a setting of 15, etc. and adding this to the UI would be simple and easy for users to understand.

Ok, I've set pollinterval = 5 and the system seems fine (uptime 2h30m)... I will check again tomorrow morning (i.e. in ~12h) to see if everything is still ok.

After 14 hours still running fine (with pollinterval = 5)

:manhappy:

Heard back from L3 support. They have found and fixed a bug in libusb that will be in beta 3.

Yes.

Please try ReadyNASOS 6.6.1-T220 (Beta 3) which is now available.

---

mdgm wrote:

Please try ReadyNASOS 6.6.1-T220 (Beta 3) which is now available.

---

Quick question - can anybody (i.e. myself) install the Beta 3 version?  Is it sufficiently stable?  I have an APC Back-UPS,405 Watts /700 VA connected by USB.

---

ScotsDon wrote:

---

mdgm wrote:

Please try ReadyNASOS 6.6.1-T220 (Beta 3) which is now available.

---

Quick question - can anybody (i.e. myself) install the Beta 3 version?  Is it sufficiently stable?  I have an APC Back-UPS,405 Watts /700 VA connected by USB.

---

It's an open beta, so anyone can download/install it.

I've had no issues with beta-2 stability on both ARM and X86 NAS.  I've installed beta-3, but it's too early to know how it compares.  The changes over beta-2 look very targetted, so I am expecting no stability problems.  But you never know, that's why there are betas.

---

StephenB wrote:

---

---

It's an open beta, so anyone can download/install it.

 

---

So why does it say:

WARNINGS:

• Unless you are advised by NETGEAR Support in a support case to update to beta software, NETGEAR Support may deny support if you are running beta software. You can seek help here on the NETGEAR Community for issues encountered on the beta.

---

Michael_Oz wrote:

---

So why does it say:

 

WARNINGS:

• Unless you are advised by NETGEAR Support in a support case to update to beta software, NETGEAR Support may deny support if you are running beta software. You can seek help here on the NETGEAR Community for issues encountered on the beta.

---

A better question for Netgear than me.  More than likely their process doesn't include keeping their world-wide support organization up to speed on every beta.  mdgm does work for Netgear, and he did request that you try it.  

6.6.1 beta can be downgraded back to production 6.6.0 if it doesn't work out for you.

Of course using it is totally up to you.  I always recommend keeping full up-to-date backups of your ReadyNAS, and that is particularly important if you are trying out beta firmware.