Re: [Nut-upsuser] permanently setting "battery.charge.low" on APC Back-UPS RS 550G
On Jun 29, 2021, at 12:27 PM, Roger Price wrote: > > On Tue, 29 Jun 2021, Ralf Fassel via Nut-upsuser wrote: > >> OS Ubuntu 20.04.2 LTS >> Network UPS Tools 2.7.4 (Debian Package nut-client 2.7.4-11ubuntu4) >> >> device.mfr: American Power Conversion >> device.model: Back-UPS RS 550G >> >> driver.name: usbhid-ups > >> Is there a way to permanently set the battery.charge.low in the >> device? Or in some config file (which)? > > Have a look at man ups.conf which has the example > > override.battery.charge.low = 30 Again, override.* is only part of the story for changing the threshold that NUT and/or the UPS uses for LB detection: https://alioth-lists.debian.net/pipermail/nut-upsuser/2021-February/012294.html TL;DR: override does not change anything on the UPS - it only changes what upsd reports. You would need to use something like "ignorelb" in addition. > I don't know if this works for a Back-UPS RS 550G ignorelb should work for any UPS, though you can only effectively set it higher than the UPS default. ___ Nut-upsuser mailing list Nut-upsuser@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
[Nut-upsuser] permanently setting "battery.charge.low" on APC Back-UPS RS 550G
OS Ubuntu 20.04.2 LTS Network UPS Tools 2.7.4 (Debian Package nut-client 2.7.4-11ubuntu4) device.mfr: American Power Conversion device.model: Back-UPS RS 550G driver.name: usbhid-ups driver.version: 2.7.4 driver.version.data: APC HID 0.96 driver.version.internal: 0.41 ups.firmware: 857.L7 .I ups.firmware.aux: L7 ups.mfr: American Power Conversion ups.mfr.date: 2019/06/11 ups.model: Back-UPS RS 550G I can set the battery.charge.low from the command line: % upsrw -s battery.charge.low=75 -u ... -p ... UPSNAME OK This works fine until the UPS is shut down after power goes down. After power is back, UPS comes back online, PC restarts, but now % upsc UPSNAME ... battery.charge.low=10 is back to the default of the device, so I have to repeat the above command. Is there a way to permanently set the battery.charge.low in the device? Or in some config file (which)? TNX R' ___ Nut-upsuser mailing list Nut-upsuser@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] NUT command LOGIN is not a login
On Tue, 29 Jun 2021, Jim Klimov wrote: Sounds reasonable to me, and hopefully might be aliased in a legacy-compatible manner (client asks with new command, if rejected try old; accept both words on server side) so it could happen in current master. Note that similar protocol changes e.g. for master vs primary were just planned as a theoretical construct, but I did not code any PoC (beside commenting the idea) nor saw any PRs to such effect. Bite-size contribution that would be a little coding and a lot of testing (combining new and old binaries as servers and clients) is welcome :) Jim Ok, I will make the change in the I-D, with a note saying that current practice is to use LOGIN. This will help a lot in explaining how upsd and upsmon operate. Roger ___ Nut-upsuser mailing list Nut-upsuser@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] NUT command LOGIN is not a login
Sounds reasonable to me, and hopefully might be aliased in a legacy-compatible manner (client asks with new command, if rejected try old; accept both words on server side) so it could happen in current master. Note that similar protocol changes e.g. for master vs primary were just planned as a theoretical construct, but I did not code any PoC (beside commenting the idea) nor saw any PRs to such effect. Bite-size contribution that would be a little coding and a lot of testing (combining new and old binaries as servers and clients) is welcome :) Jim On Tue, Jun 29, 2021, 11:00 Roger Price wrote: > On Sat, 26 Jun 2021, Manuel Wolfshant wrote: > > On 6/26/21 10:26 AM, Roger Price wrote: > >> On Fri, 25 Jun 2021, Mark Hansen wrote: > >>> On 6/24/2021 5:48 AM, Roger Price wrote: > Comment: had the command LOGIN been called SETACTIVE, with the > upsmon flag ST_LOGIN changed to ST_ACTIVE, and NUMLOGINS changed to > NUMACTIVE this mechanism would probably be easier to understand. > LOGOUT might be NOTACTIVE. > > Current Proposed > LOGIN SETACTIVE > LOGOUTNOTACTIVE > NUMLOGINS NUMACTIVE > ST_LOGIN ST_ACTIVE > >> > >>> What about: > >>> CurrentProposed > >>> LOGIN ATTACH > >>> LOGOUT DETACH > >>> NUMLOGINS NUMATTACHED > >>> ST_LOGIN ST_ATTACHED > >> > >> Better. ATTACH is simpler and clearer than SETACTIVE. Roger > > > > +1 ! > > Jim, I would like to suggest this as a change to NUT - not something to be > done > for the next release, but, like some other things in the draft RFC (I-D), > as a > statement of direction for the project. > > If the project as a whole can agree on this, I will make the change LOGIN > -> > ATTACH in the I-D with a note saying that current practice is to use > LOGIN. Do > we need to vote? > > Roger___ > Nut-upsuser mailing list > Nut-upsuser@alioth-lists.debian.net > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser > ___ Nut-upsuser mailing list Nut-upsuser@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] NUT command LOGIN is not a login
On Sat, 26 Jun 2021, Manuel Wolfshant wrote: On 6/26/21 10:26 AM, Roger Price wrote: On Fri, 25 Jun 2021, Mark Hansen wrote: On 6/24/2021 5:48 AM, Roger Price wrote: Comment: had the command LOGIN been called SETACTIVE, with the upsmon flag ST_LOGIN changed to ST_ACTIVE, and NUMLOGINS changed to NUMACTIVE this mechanism would probably be easier to understand. LOGOUT might be NOTACTIVE. Current Proposed LOGIN SETACTIVE LOGOUT NOTACTIVE NUMLOGINS NUMACTIVE ST_LOGIN ST_ACTIVE What about: Current Proposed LOGIN ATTACH LOGOUT DETACH NUMLOGINS NUMATTACHED ST_LOGIN ST_ATTACHED Better. ATTACH is simpler and clearer than SETACTIVE. Roger +1 ! Jim, I would like to suggest this as a change to NUT - not something to be done for the next release, but, like some other things in the draft RFC (I-D), as a statement of direction for the project. If the project as a whole can agree on this, I will make the change LOGIN -> ATTACH in the I-D with a note saying that current practice is to use LOGIN. Do we need to vote? Roger___ Nut-upsuser mailing list Nut-upsuser@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser