similar to: Discussion about legalizing some `ups.status` tokens

Hi ups-devel, As I looked throw www.networkupstools.org site, haven't found any pointers where to send patches, so I hope this is the right place. (Please let me know weather this is the right place.) The patch contains a minor change in the logic of the driver, our Effekta MHD 3000 UPS continuously writes status data to the serial port, so one has to send a CR character and empty the

On Feb 11, 2008 5:30 PM, Marcio Gomes <mpg at microlink.com.br> wrote: > I change the if in [OFF] detect state to, in original way, if you send a > reset.watchdog, the UPS goes > to OFF state in clients, but it is not correct, because UPS is OL and > Shutdown are in progress, but > the power is not OFF First of all, thanks for the patch. But I have a few comments: Are you

I have added preliminary support for the TrippLite protocol number 2001 into tripplite_usb.c. The attached file is supplied as a patch against today's SVN. This patch adds support for TrippLite SMART550USB and some Omni models. Tested are On Line, On Battery, Battery Good, and Battery Bad indication. Everything else seems to work, but this UPS is attached to a critical system, and I can

Errata coming up for NUT v2.8.2: * it was discovered that the nut-driver-enumerator (NDE) script had a regression which caused it to not reload nut-driver instances (systemd, SMF) when `ups.conf` edits happened. * on a related note, it may be possible that "live" driver reloading (at least on master branch) does not reduce debug verbosity to zero when `debug_min 0` is active in its

Errata coming up for NUT v2.8.2: * it was discovered that the nut-driver-enumerator (NDE) script had a regression which caused it to not reload nut-driver instances (systemd, SMF) when `ups.conf` edits happened. * on a related note, it may be possible that "live" driver reloading (at least on master branch) does not reduce debug verbosity to zero when `debug_min 0` is active in its

Hello all, After a prolonged labour with a few re-issues of the tag and many pushes during the day, NUT v2.8.2 was found in a strange egg by a bunny hopping away from the April fools. All that - blessed under the shine of Polar lights in the middle of the icy North Ocean. A python module was released but slipped away with an earlier commit. Other artifacts should follow shortly. Jim Klimov

Hello all, After a prolonged labour with a few re-issues of the tag and many pushes during the day, NUT v2.8.2 was found in a strange egg by a bunny hopping away from the April fools. All that - blessed under the shine of Polar lights in the middle of the icy North Ocean. A python module was released but slipped away with an earlier commit. Other artifacts should follow shortly. Jim Klimov

sent two 0 byte packets to the driver, then it sent 'URB_FUNCTION_SYNC_REST_PIPE_AND_CLEAR_STALL' down the pipe which seems to come back up as well, and then the UPS turned off. I'll play around later with what happens in that regard, although it may be a bit tricky to figure out when the battery is low without having it plugged in ;-) Also, about nut-usbups.rules.in... The

sent two 0 byte packets to the driver, then it sent 'URB_FUNCTION_SYNC_REST_PIPE_AND_CLEAR_STALL' down the pipe which seems to come back up as well, and then the UPS turned off. I'll play around later with what happens in that regard, although it may be a bit tricky to figure out when the battery is low without having it plugged in ;-) Also, about nut-usbups.rules.in... The

sent two 0 byte packets to the driver, then it sent 'URB_FUNCTION_SYNC_REST_PIPE_AND_CLEAR_STALL' down the pipe which seems to come back up as well, and then the UPS turned off. I'll play around later with what happens in that regard, although it may be a bit tricky to figure out when the battery is low without having it plugged in ;-) Also, about nut-usbups.rules.in... The

The tripplite driver was developed on a machine with a reliable serial connection, and inherited the assumption that the serial line connection would not drop, reorder, or fail character read and writes. This patch adds significantly improved failure mode handling and also does basic checks of data validity. There's also a few minor cleanups/beautification. I've tested this code on my

A hiccup was reported about validating the tarball signature on some systems, so it was reissued from another workstation. Please don't worry :) Jim Klimov On Tue, Apr 2, 2024, 01:06 Jim Klimov <jimklimov+nut at gmail.com> wrote: > Hello all, > > After a prolonged labour with a few re-issues of the tag and many pushes > during the day, NUT v2.8.2 was found in a strange

A hiccup was reported about validating the tarball signature on some systems, so it was reissued from another workstation. Please don't worry :) Jim Klimov On Tue, Apr 2, 2024, 01:06 Jim Klimov <jimklimov+nut at gmail.com> wrote: > Hello all, > > After a prolonged labour with a few re-issues of the tag and many pushes > during the day, NUT v2.8.2 was found in a strange

I updated 3 Pi OS systems with v2.8.2. So far all are running without error. Raspberry PI 2, Pi 3 and Pi 5. Debian 12 (bookworm). Dan -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://alioth-lists.debian.net/pipermail/nut-upsuser/attachments/20240407/74832090/attachment-0001.htm>

Best fortress support was understandably dropped, but we still use them, and someone else may want the driver I ported to nut-2.0. We also often attach the serial cable from a UPS to a network terminal server, since servers these days don't come with very many serial ports. (They call them "legacy" ports.) I submitted a patch to support these for nut-1.x, and it was rejected

Alex, ping? There was a thread about moving Risc-V out of experimental but I think it didn't go anywhere? Separately, do the listed patches sound okay for merging? Thanks, Hans On Fri, Jan 25, 2019 at 4:40 PM Bruce Hoult <brucehoult at sifive.com> wrote: > > In https://llvm.org/svn/llvm-project/llvm/branches/release_80 I find > that RISCV is still in

Dear NUT developers, I am using NUT + bcmxcp + Powerware 9315. I would like to use NUT to shut down my systems if the air conditioning fails and the room get too hot. I want the same shutdown sequence as would be produced when the UPS goes on battery. The UPS has a terminal block at the front for up to six different 'building alarms'. I can connect a thermostat (35C) to the

I'm a long-time user of APC UPSs and apcupsd, but have been experiencing issues with recent APC units, although I have three BackUPS CS650 units which have had very little issue.. I've recently replaced the APC 1200 unit on my fileserver (running Slackware) with a CyberPower UPS and that appears to be well supported by NUT. However, I have an APC BX950MI unit which is currently being

On Wed, 8 Apr 2020 at 04:23, Kai Wang <kai.wang at sifive.com> wrote: > If we apply the type system pointed out by Renato, is the vector type <vscale x 1 x i16> legal? If we decide that <vscale x 1 x i16> is a fundamentally impossible type, does it contrary to the philosophy of LLVM IR as reasonably target-independent IR? I do not get the point of your argument. Hi Kai,

Hey all, I am trying to implement a subtarget for the X86 architecture that only has 64 bit Registers. While running LLC on the IR for a very simple program, llc fails on an assertion that says it doesn't know how to promote ISD::FRAMEINDEX. I've tried to look for why how to promote the frameindex which is stored in a i32 variable to an i64 variable but can't seem to find where