similar to: Introducing `sdcommands` option and `shutdown.default` INSTCMD to all drivers

Hi I am considering adding support in the bcmxcp driver for the following commands available in bcmxcp specification : #define PW_UPS_ON .. /* UPS on command. length 1-2 */ #define PW_UPS_ON_TIME .. /* Scheduled UPS on in n minutes. length 3-4 */ #define PW_UPS_ON_AT_TIME .. /* Schedule UPS on at specified date and time. length 7-8 */ #define

Hello, we have a problem using APC Back-UPS CS 500 (connected via USB, usbhid-ups-apc) and UPS-NUT. We've tried different Versions of UPS-NUT (2.2.1 and 2.2.2), including the latest from SVN (28th November 2008). We've also tried apcupsd, which works fine for our requirements, but we don't want use it. What we need is simple: The UPS should turn off after power loss and shutdown

Hello world! Please, help me :-) I have a APC RS-800 usb and it don't shutdown. I try every things but nothing: don't shutdown. Uhmmmm My actual situation: tux:/home/effem# uname -a Linux tux 2.6.26-1-686 #1 SMP Wed Aug 20 12:56:41 UTC 2008 i686 GNU/Linux tux:/home/effem# wajig policy nut nut: Installato: 2.2.2-6 Candidato: 2.2.2-6 Tabella versione: 2.2.2-7 0 -20

On Dec 20, 2017, at 10:32 AM, Ken Olum wrote: > > 0.090564 find_nut_info: unknown info type: load.on.delay > 0.090577 find_nut_info: unknown info type: load.on.delay > 0.090585 Initiating UPS shutdown > 0.090593 upsdrv_shutdown... > 0.090601 instcmd(shutdown.return, [NULL]) > 0.090614 find_nut_info: unknown info type: shutdown.return > 0.090624

Device manufacturer: Fideltronik INIGO Device name: Viper 1200 Device type: UPS Bus type: USB WWW: http://fideltronikinigo.com/viper/viper-1200/ " nut-scanner -U" output: [nutdev1] driver = "blazer_usb" port = "auto" vendorid = "0001" productid = "0000" product = "MEC0003" vendor =

while finishing some work on the HAL integration (I'm now mapping DBus method with NUT commands, to allow at least the final UPS poweroff), I was horrified to realize (and so late) the changes in usbhid-ups->upsdrv_shutdown(). We've lost a lot there, but making a generic code, instead of keeping the subdrivers delegation. For example, the shutdown.return command (which is or should be

On 10/14/2015 12:18 PM, Roger Price wrote: > Is there any command in the list provided by "upscmd -l myups" which is accepted > by this UPS? None of the command sin the list successfully completes, not even beeper.toggle. My list: # upscmd -l myups Instant commands supported on UPS [myups]: beeper.toggle - Toggle the UPS beeper load.off - Turn off the load

While working on the mge-hid subdriver, I wanted to add the 'beeper.mute' command. Unfortunately, the description I intended to use was used already by the 'beeper.off' instcmd: CMDDESC beeper.off "Temporarily mute the UPS beeper" Now of course we could add another instcmd 'beeper.reallyoff', but instead I would prefer to bite the buller and do the following:

Hi Inspired by the changes by Prachi Gandhi to use the command map from the UPS in the bcmxcp driver, I think the map should be used, if available, to control all commands the driver adds using "dstate_addcmd". The following patch is an attempt at doing so. The patch is against the bcmxcp branch. Since my UPS also supports : #define PW_UPS_ON (unsigned char)0x89 /* UPS on

Hello all, As the holiday season looms upon us, and NUT cracker sounds can be heard everywhere, I wonder if the current codebase is good enough to cut a 2.8.3 release some time soonish. Active development of recently contributed drivers has somewhat subsided; there are still some planned revisions (notably about documentation and statuses for ECO and similar modes), but some more get shelved

Hello all, As the holiday season looms upon us, and NUT cracker sounds can be heard everywhere, I wonder if the current codebase is good enough to cut a 2.8.3 release some time soonish. Active development of recently contributed drivers has somewhat subsided; there are still some planned revisions (notably about documentation and statuses for ECO and similar modes), but some more get shelved

On Sat, May 28, 2016 at 11:05 AM, abi <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 instcmd(shutdown.return, [NULL]) > 0.145767 powercom_shutdown_nuf: value = (null), command = 5400 > 0.145770

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

Hello. Not listed as supported, so here is some info, [root at vhost ~]# /usr/sbin/usbhid-ups -DD -a powercom Network UPS Tools - Generic HID driver 0.38 (2.7.2) USB communication driver 0.32 0.000000 debug level is '2' 0.001318 upsdrv_initups... 0.074753 Checking device (0529/0001) (003/002) 0.074835 Failed to open device, skipping. (Permission denied)

Hello! I'm a total noob in the NUT world, and have 0 experience dealing with Linux distributions. Since NUT is poorly ported to Windows it's driving me crazy, I hope you can help me. I have, after 3 days of painful reading, testing and failing, successfully set up NUT to communicate with my cheap-ass line-interactive 1000VA Chinese UPS (just no brand at all, it is a locally rebranded UPS,

Thanks for your help. From: Charles Lepple <clepple at gmail.com> Date: Mon, 18 Dec 2017 19:26:56 -0500 This may sound like an apples-to-oranges comparison, but we did uncover an issue with CyberPower UPSes where the delay values needed to be greater than or equal to 60 (seconds), since they were being rounded down to integer numbers of minutes internally: What was the largest

It seems that the UPS I wrote in my previous mail uses the Megatec protocol, but does not support the S<n>R<m> "Shut Down and Restore" Command. This means that the server will shut down cleanly, but it will not boot automatically when the utility power comes back. There is another shutdown command according to the protocol description, although I do not really understand the

On Nov 1, 2014, at 9:28 PM, hyouko at gmail.com wrote: > Provided that the subdriver works, I'd like to see, if possible, the logs of: > - driver startup > - a command that succeeds > - a command that fails > - q1 when online and all's ok > - q1 on battery > - setting pins_shutdown_mode Attached is a log of most of these conditions. Looks like reading the status for

On Wed, 14 Oct 2015, Davide Baldini wrote: > upsdrvctl shutdown > ... > instcmd(shutdown.return, [NULL]) > instcmd: FAILED > Shutdown failed! > Driver failed to start (exit status=1) > > This time /var/log/syslog doesn't register anything about the UPS after > issuing the command above. Instead, It logged some errors after a > upscmd -u admin -p mypass

On Aug 22, 2018, at 1:20 PM, Karol Olszewski <karol.olszewski at ipflow.pl> wrote: > > W dniu 22.08.2018 o 14:41, Charles Lepple pisze: >> /lib/nut/usbhid-ups -a apc -DDD -k > Please see attachement. 1.872180 Report[buf]: (2 bytes) => 40 00 1.872196 Path: UPS.Output.APCDelayBeforeReboot, Type: Feature, ReportID: 0x40, Offset: 0, Size: 8, Value: 0 [...] 1.872439