For what it's worth, productID should = protocol number.

I think objecttothis had 2012 but Scott had 3024. A lot of our smaller standby 
and line-interactive units recently changed to 302x protocols, hence this post 
to the development list:
https://alioth-lists.debian.net/pipermail/nut-upsdev/2020-June/007473.html

In any case, the support team or I can confirm if you send us serial numbers.

Thank you,
David Zomaya
Tripp Lite











From: Nut-upsuser 
<nut-upsuser-bounces+david_zomaya=tripplite....@alioth-lists.debian.net> on 
behalf of objecttothis <[email protected]>
Sent: Wednesday, July 22, 2020 8:57 AM
To: [email protected]
Subject: [EXTERNAL] [Nut-upsuser] AVRX750/500 issues

This is an EXTERNAL email.  Please take a moment and think before clicking any 
links or opening any attachments from this email.  If suspicious, please 
forward to [email protected] for review.

______________________________________________________________________
I wouldn't be surprised if they both use the same driver.  I think they are 
essentially the same model, but with one having a slightly larger battery.  My 
issue is primarily with the UPS turning back on after having shut off like it 
should.  @Scott Colby if  you take a look at the config files I posted in the 
github issue I created, perhaps that will give you some hints on your issue. 
Maybe there are differences in the config that would give you a clue as to why 
your Pi isn't shutting off.  Does it work properly  if you have it shut down 
from a timer instead of low battery?  Are you wanting your UPS to turn back on 
after a delay, or just turn back on when power is restored to the mains?

-----Original Message-----
From: Nut-upsuser 
<nut-upsuser-bounces+objecttothis=gmail....@alioth-lists.debian.net> On Behalf 
Of [email protected]
Sent: Wednesday, July 22, 2020 3:00 PM
To: [email protected]
Subject: Nut-upsuser Digest, Vol 181, Issue 5

Send Nut-upsuser mailing list submissions to
        [email protected]

To subscribe or unsubscribe via the World Wide Web, visit
         
https://urldefense.proofpoint.com/v2/url?u=https-3A__alioth-2Dlists.debian.net_cgi-2Dbin_mailman_listinfo_nut-2Dupsuser&d=DwIGaQ&c=f9s1WCuF-N6cmD_YaZ7gBg&r=lhr3k4au5dVQgHY_iS-v_t9g8PHVkn8Px_wyaupZGfQ&m=vC2kcmM-UcihmSZxRAeTUX22fYSlpXNHw9rpFUxfGiQ&s=Rpy7pnwa-6z9Wx0ikcpNLFh4nTj6tRsEueSvrXsU0Q4&e=
or, via email, send a message with subject or body 'help' to
        [email protected]

You can reach the person managing the list at
        [email protected]

When replying, please edit your Subject line so it is more specific than "Re: 
Contents of Nut-upsuser digest..."


Today's Topics:

   1. Re: AVR750U Low Power not Triggering Shutdown (Scott Colby)


----------------------------------------------------------------------

Message: 1
Date: Wed, 22 Jul 2020 00:07:03 -0400
From: "Scott Colby" <[email protected]>
To: [email protected]
Cc: [email protected]
Subject: Re: [Nut-upsuser] AVR750U Low Power not Triggering Shutdown
Message-ID: <[email protected]>
Content-Type: text/plain

Hello again,

I had to take a hiatus from troubleshooting this issue, but I'm back now with 
new information. As before, I am working with a TrippLite AVR750U purchased 
earlier this year. However, I've switched from the FreeBSD-based router to a 
Debian-based Raspberry Pi  for reasons that are probably not worth explaining 
at the moment :^)

I've included my current configuration files at the bottom of this message.

I've run a few experiments to try to determine what's going on here.
I'll include the shell command and any output delimited by ###'s, followed by 
my observation of the behavior of the Raspberry Pi and the UPS.

First Experiment
################
$ sudo upsmon -c fsd
Network UPS Tools upsmon 2.7.4

Broadcast message from nut@raspi (somewhere) (Tue Jul 21 23:27:01

Executing automatic power-fail shutdown



Broadcast message from nut@raspi (somewhere) (Tue Jul 21 23:27:01

Auto logout and shutdown proceeding

$ Connection to pi closed by remote host.
Connection to pi closed.
################

I ran this command under two sets of conditions:

- UPS plugged in to the mains
- UPS unplugged from the mains, then plugging it back in approximately
  60 seconds after it turned off

In both cases, the Pi shut down cleanly after approximately 5 seconds 
(FINALDELAY?), and the UPS turned off after approximately 25 seconds 
(FINALDELAY + the default offdelay?) However, the UPS never came back up.

Second Experiment
#################
$ sudo upsdrvctl shutdown
Network UPS Tools - UPS driver controller 2.7.4 Network UPS Tools - Generic HID 
driver 0.41 (2.7.4) USB communication driver 0.33 Using subdriver: TrippLite 
HID 0.82 Initiating UPS shutdown #################

Nothing happened as far as I can tell. I waited 2 minutes before moving on.

Third Experiment
################
$ sudo /lib/nut/usbhid-ups -a AVR750U -k Network UPS Tools - Generic HID driver 
0.41 (2.7.4) USB communication driver 0.33 Using subdriver: TrippLite HID 0.82 
Initiating UPS shutdown $ Connection to pi closed.
################

The UPS turned off after approximately 20 seconds, but there was no clean shut 
down of the Pi. I think this is expected.

Fourth Experiment
#################
$ sudo upscmd -u admin -p passw0rd AVR750U shutdown.return OK #################

I also ran this experiment under two conditions:
- UPS plugged into the mains
- UPS unplugged then reconnected approximately 30 seconds after
  shutdown

In the first case, nothing happened. In the second case, the UPS shut off after 
20 seconds. However, it did not turn back on after I reconnected it to power.

Fifth Experiment
################
To answer Roger's questions, I did the following:

- ran `upslog -f '{"time": "%TIME @Y-@m-@dT@H:@M:@S%", "charge": %VAR 
battery.charge%, "status": "%VAR ups.status%", "runtime": %VAR 
battery.runtime%}' -i 10 -l upslog.jsonl -s AVR750U` and tailed its output
- unplugged from the mains and observed a wall message and status
  change from upslog
- reconnected to the mains and observed a wall message and status
  change
- unplugged again and observed another wall message and status
  change
- waited for the battery to run down
- here's an extract from that log:
{"time": "2020-07-22T02:20:22", "charge": 3, "status": "OB DISCHRG", "runtime": 
138}
{"time": "2020-07-22T02:20:32", "charge": 3, "status": "OB DISCHRG", "runtime": 
128}
{"time": "2020-07-22T02:20:42", "charge": 3, "status": "OB DISCHRG", "runtime": 
123}
{"time": "2020-07-22T02:20:52", "charge": 2, "status": "OB DISCHRG", "runtime": 
108}
{"time": "2020-07-22T02:21:02", "charge": 2, "status": "OB DISCHRG", "runtime": 
98}
{"time": "2020-07-22T02:21:12", "charge": 2, "status": "OB DISCHRG", "runtime": 
93}
{"time": "2020-07-22T02:21:22", "charge": 2, "status": "OB DISCHRG", "runtime": 
77}
{"time": "2020-07-22T02:21:32", "charge": 1, "status": "OB DISCHRG", "runtime": 
67}
{"time": "2020-07-22T02:21:42", "charge": 1, "status": "OB DISCHRG", "runtime": 
62}
{"time": "2020-07-22T02:21:52", "charge": 1, "status": "OB DISCHRG", "runtime": 
52}
{"time": "2020-07-22T02:22:02", "charge": 0, "status": "OB DISCHRG", "runtime": 
41}
{"time": "2020-07-22T02:22:12", "charge": 0, "status": "OB DISCHRG", "runtime": 
31}
{"time": "2020-07-22T02:22:22", "charge": 0, "status": "OB DISCHRG", "runtime": 
21}
{"time": "2020-07-22T02:22:32", "charge": 0, "status": "OB DISCHRG", "runtime": 
11}
{"time": "2020-07-22T02:22:42", "charge": 0, "status": "OB DISCHRG", "runtime": 
1}
{"time": "2020-07-22T02:22:52", "charge": 0, "status": "OB DISCHRG", "runtime": 
0}
{"time": "2020-07-22T02:23:02", "charge": 0, "status": "OB DISCHRG", "runtime": 
0}
{"time": "2020-07-22T02:23:12", "charge": 0, "status": "OB DISCHRG", "runtime": 
0}
{"time": "2020-07-22T02:23:22", "charge": 0, "status": "OB DISCHRG", "runtime": 
0}
{"time": "2020-07-22T02:23:32", "charge": 0, "status": "OB DISCHRG", "runtime": 
0} ...
{"time": "2020-07-22T03:19:52", "charge": 0, "status": "OB DISCHRG", "runtime": 
0}
{"time": "2020-07-22T03:20:02", "charge": 0, "status": "OB DISCHRG", "runtime": 
0}
{"time": "2020-07-22T03:20:12", "charge": 0, "status": "OB DISCHRG", "runtime": 
0}
{"time": "2020-07-22T03:20:22", "charge": 0, "status": "OB DISCHRG", "runtime": 
0}
{"time": "2020-07-22T03:20:32", "charge": 0, "status": "OB DISCHRG", "runtime": 
0}
{"time": "2020-07-22T03:20:42", "charge": 0, "status": "OB DISCHRG", "runtime": 
0}
{"time": "2020-07-22T03:20:52", "charge": 0, "status": "OB DISCHRG", "runtime": 
0}

- !!!!! it ran for almost an hour on charge 0 runtime 0 and never
  raised the LB flag

################

So, here are my questions:

- Have I made a configuration error?
- Why is the behavior of `upsdrvctl shutdown` different from that
  of `usbhid-ups -k`?
- Why doesn't the UPS ever turn back on on its own?
- What's going on with the LB flag never coming on and the runtime
  being badly wrong?

I'm wondering if this is related to what objecttothis is experiencing with the 
AVRX500U. I'll CC them on this message. Further, I will reach out to TrippLite 
support to ask what version of the USB HID protocol my AVR750U is using.

Thanks,
Scott




My Configuration
################

# /etc/udev/rules.d/62-nut-usbups-custom.rules
# based on the 62-nut-usbups.rules that came with the package 
ACTION!="add|change", GOTO="nut-usbups_rules_end"
SUBSYSTEM=="usb_device", GOTO="nut-usbups_rules_real"
SUBSYSTEM=="usb", GOTO="nut-usbups_rules_real"
SUBSYSTEM!="usb", GOTO="nut-usbups_rules_end"
LABEL="nut-usbups_rules_real"
# TrippLite
#  e.g. TrippLite AVR750U  - usbhid-ups
ATTR{idVendor}=="09ae", ATTR{idProduct}=="3024", MODE="664", GROUP="nut"
LABEL="nut-usbups_rules_end"

# nut.conf
MODE=standalone

# ups.conf
[AVR750U]
    driver = usbhid-ups
    productid = 3042
    port = auto

# upsd.conf
# empty

# upsd.users
[admin]
    password = passw0rd
    instcmds = ALL
[upsmon]
    password = passw0rd
    upsmon master

# upsmon.conf
MONITOR AVR750U 1 upsmon passw0rd master MINSUPPLIES 1 SHUTDOWNCMD 
"/sbin/shutdown -h +0"
POLLFREQ 5
POLLFREQALERT 5
HOSTSYNC 15
DEADTIME 15
POWERDOWNFLAG /etc/killpower
RBWARNTIME 43200
NOCOMMWARNTIME 300
FINALDELAY 5



------------------------------

Subject: Digest Footer

_______________________________________________
Nut-upsuser mailing list
[email protected]
https://urldefense.proofpoint.com/v2/url?u=https-3A__alioth-2Dlists.debian.net_cgi-2Dbin_mailman_listinfo_nut-2Dupsuser&d=DwIGaQ&c=f9s1WCuF-N6cmD_YaZ7gBg&r=lhr3k4au5dVQgHY_iS-v_t9g8PHVkn8Px_wyaupZGfQ&m=vC2kcmM-UcihmSZxRAeTUX22fYSlpXNHw9rpFUxfGiQ&s=Rpy7pnwa-6z9Wx0ikcpNLFh4nTj6tRsEueSvrXsU0Q4&e=

------------------------------

End of Nut-upsuser Digest, Vol 181, Issue 5
*******************************************


_______________________________________________
Nut-upsuser mailing list
[email protected]
https://urldefense.proofpoint.com/v2/url?u=https-3A__alioth-2Dlists.debian.net_cgi-2Dbin_mailman_listinfo_nut-2Dupsuser&d=DwIGaQ&c=f9s1WCuF-N6cmD_YaZ7gBg&r=lhr3k4au5dVQgHY_iS-v_t9g8PHVkn8Px_wyaupZGfQ&m=vC2kcmM-UcihmSZxRAeTUX22fYSlpXNHw9rpFUxfGiQ&s=Rpy7pnwa-6z9Wx0ikcpNLFh4nTj6tRsEueSvrXsU0Q4&e=

________________________________
 This message is for the addressee's use only. It may contain confidential 
information. If you receive this message in error, please delete it and notify 
the sender. Tripp Lite disclaims all warranties and liabilities, and assumes no 
responsibility for viruses which may infect an email sent to you from Tripp 
Lite and which damage your electronic systems or information. It is your 
responsibility to maintain virus detection systems to prevent damage to your 
electronic systems and information.

_______________________________________________
Nut-upsuser mailing list
[email protected]
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser

Reply via email to