similar to: SU2200RTXLCD2U and protocol 4006

Thank you for your answer. I will try to investigate the possibility that the Tripplite serial cable has a different pinout than a standard RS-232 serial cable. I wouldn't use the NUT at this point because I don't think I will be able to write a software update to adapt the NUT to my needs. My idea was first to test the protocol via a serial terminal client directly connected to the UPS,

I don't have the Tripp-Lite model that you have, however the NUT HCL http://networkupstools.org/stable-hcl.html suggests that the SU2200RTXLCD2U ought to work via USB. Tripp-Lite sometimes uses proprietary serial cables, so you may need to hunt down a pinout for the serial cable this unit requires. If you need to use a serial connection, I'd start by looking at how their PowerAlert

Hello I am trying to install the NUT on CentOS 6 (2.6.32-696.3.1.el6.x86_64). First I installed it using: yum install epel-release --enablerepo=extras yum install nut And when I run it by: sbin/upsdrvctl start (that's where it installed it using the package) I had the following message: "This TrippLite device (09ae:1330) is not (or perhaps not yet) supported by usbhid-ups. [...]"

On 06/24/2017 04:52 AM, Charles Lepple wrote: > On Jun 23, 2017, at 5:50 PM, Ambrogio Coletti <ambrojohn at gmail.com> wrote: >> "This TrippLite device (09ae:1330) is not (or perhaps not yet) supported by usbhid-ups. [...]" >> but my device (SU2200RTXLCD2U) is supported, as clearly state here. > No, the HCL also mentions "protocol 4001". For Tripp-Lite,

>From section 4.23 of the Developer Guide: "There are a few USB UPS devices that are not HID devices. These devices typically implement some version of the manufacturer?s serial protocol over USB (which is a really dumb idea, by the way). An example is the Tripplite USB. Such devices are *not* supported by the usbhid-ups driver, and are not covered in this document." I guess that

On 07/06/2017 02:18 AM, Charles Lepple wrote: > On Jul 5, 2017, at 5:34 PM, Ambrogio Coletti <ambrojohn at gmail.com > <mailto:ambrojohn at gmail.com>> wrote: >> >> From section 4.23 of the Developer Guide: >> >> "There are a few USB UPS devices that are not HID devices. These >> devices typically implement some version of the manufacturer?s

On Jul 3, 2017, at 12:48 PM, Ambrogio Coletti wrote: > > I wouldn't use the NUT at this point because I don't think I will be able to write a software update to adapt the NUT to my needs. > > My idea was first to test the protocol via a serial terminal client directly connected to the UPS, and then write some simple code from scratch to implement the protocol and use it for

Larry, I have not edited a single file, including anything to do with NUT, on the Synology via ssh.... ever. How is yours configured in the UI? Do you have it set to go into safe mode after a certain number minutes? Earlier, I was just copying and pasting the contents of some files to Roger but did not change anything. -- Todd Benivegna // todd at benivegna.com On Aug 14, 2020, 8:16 AM -0400,

Thanks Larry, no problem. I appreciate the input. Whenever you get a chance I’d really like to compare notes with someone who has NUT and a Synology to see why the heck mine doesn’t work! ;). I’m also using my Pi as the master like you. Thanks. Todd -- Todd Benivegna // todd at benivegna.com On Aug 14, 2020, 11:55 AM -0400, Larry Fahnoe <fahnoe at fahnoetech.com>, wrote: > On Fri, Aug

Roger, Thanks for the idea to add additional items to the notifyflag. That proved the monitor was indeed working as expected and led me to find that my script had myriad issues when run under the nut user. All remedied now. As I progress, I may well end up migrating to the upssched. As a newbie I was simply following the documented "simple" way described here

On Fri, 22 May 2020, Tom Cooper wrote: > Sadly I am still seeing a loss of communication. I will check the device number to see if it has changed.  > Not sure what else to look at. I guess I could create a corn job to restart the driver multiple times a day.  If there is a command such as upsc for which the output depends on the driver running correctly, then it might be better to run a

Roger, I get 4.3.8(1)-release There was good reason, BTW, for the script to NOT fine the journal script on my machine. I had not downloaded it yet. On 7/14/2019 9:06 AM, Roger Price wrote: > On Sun, 14 Jul 2019, David White wrote: > >> ... I saw nothing that looked like a problem with the report save the >> sections <scriptname> "Cannot access <scriptname>.

On Sat, Jul 22, 2017 at 7:48 AM, Charles Lepple <clepple at gmail.com> wrote: > > I also have not used a Synology device, but as I recall, they generally > expect to be the NUT master system. This may cause problems if you need to > do something fancy with upssched. > The Synology boxes work fine as NUT clients, *however* they provide very little ability to configure NUT

> > > 2.117586 send_cmd(msg_len=2, type='G') > > 3.219418 libusb_get_interrupt: Connection timed out > > 3.219474 libusb_get_interrupt() returned 0 instead of 8 while > sending 3a 47 b8 0d 00 00 00 00 '.G......' > > 4.219593 libusb_get_interrupt: Connection timed out > > 4.219661 libusb_get_interrupt() returned

Hello I am not a linux expert. The output of uname -r on my system returns: 2.6.32-696.3.1.el6.x86_64 hence I am trying to install this rpm: sudo yum install nut-2.7.4-9.fc27.x86_64.rpm but I got failed dependencies. Is there a repository I am supposed to set up to get those dependencies from? Regards Ambrogio -------------- next part -------------- An HTML attachment was scrubbed... URL:

On Apr 13, 2018, at 3:55 AM, Jon Bendtsen <jon.bendtsen at jonix.dk> wrote: > > On 13/04/2018 07.56, zefanjas wrote: >> Hi, >> is there a command to get a list of connected slaves you can run on the >> nutserver? I want to monitor the slaves and if their are actually >> connected to server. > > if there is no such command in NUT, then on my Debian

So I finally got a test in after I changed my RPi to the master and everything else (including my Synology) to slaves.  Before I did that though, I timed the shutdown of my Synology since it is the slowest slave to shutdown.  It took 40 seconds to shutdown, so I changed HOSTSYNC in upsmon.conf on the master (“Proton”) to 60.  I then did a test ("sudo upsmon -c fsd”). The slaves shutdown, then

On Mon, 10 Aug 2020, Todd Benivegna wrote: > synoups: https://hastebin.com/xexafofiha.bash Wow! What a mess. It looks as if Synology wanted to write their own "NUT", but decided it would be easier to put their ideas in a script when they saw they could use upssched.conf to call it. NUT intends such a script for timer management. Synology use it for general system management.

On 28.05.2016 19:46, Larry Fahnoe wrote: > On Sat, May 28, 2016 at 11:05 AM, abi <abi at abinet.ru > <mailto:abi at abinet.ru>> wrote: > > However I was unable to shutdown.return it. Maybe protocol is not > fully compatible? > > 0.145757 Initiating UPS shutdown > 0.145760 upsdrv_shutdown... > 0.145763

On Monday 22 June 2020 15:36:21 Charles Lepple wrote: > On Jun 22, 2020, at 1:26 PM, Gene Heskett wrote: > > So I just edited /etc/nut/upsd.users to add both the commands it > > claims to have but get this response to either: > > In your original example, you had multiple “instcmd =“ lines for one > user- I think the allowed commands all need to be listed on one >