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.com at
alioth-lists.debian.net> on behalf of objecttothis <objecttothis at
gmail.com>
Sent: Wednesday, July 22, 2020 8:57 AM
To: nut-upsuser at alioth-lists.debian.net
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 ishelpdesk at tripplite.com 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.com at
alioth-lists.debian.net> On Behalf Of nut-upsuser-request at
alioth-lists.debian.net
Sent: Wednesday, July 22, 2020 3:00 PM
To: nut-upsuser at alioth-lists.debian.net
Subject: Nut-upsuser Digest, Vol 181, Issue 5
Send Nut-upsuser mailing list submissions to
nut-upsuser at alioth-lists.debian.net
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&eor,
via email, send a message with subject or body 'help' to
nut-upsuser-request at alioth-lists.debian.net
You can reach the person managing the list at
nut-upsuser-owner at alioth-lists.debian.net
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" <scott at scolby.com>
To: nut-upsuser at alioth-lists.debian.net
Cc: objecttothis at gmail.com
Subject: Re: [Nut-upsuser] AVR750U Low Power not Triggering Shutdown
Message-ID: <4f09187f-5718-4202-9550-3a61037deef9 at www.fastmail.com>
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 at raspi (somewhere) (Tue Jul 21 23:27:01
Executing automatic power-fail shutdown
Broadcast message from nut at 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- at m-@dT at
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
Nut-upsuser at alioth-lists.debian.net
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
Nut-upsuser at alioth-lists.debian.net
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.