similar to: usbhid-ups: shutdown testing needed

Folks, I think the present megatec_usb.c deserves to be renamed to serial_usb.c. I think it potentially could serve many more UPS'es with built-in USB-to-serial converters, not limited to the megatec_usb driver (although that was the first one to use this). I also think a more layered approach would be nice, in the same fashion as the usbhid-ups driver with subdrivers. Which would mean that

Peter, What is your opinion on the following idea. I think we can improve the matching a lot, by delaying the exact matcher to *after* parsing the Report Descriptor and applying subdriver specific routines to get to the serial number, model and vendor names. By doing so, we would probably get more accurate information on especially the serial number, since this is located in non-standard

Hi all, I attached a driver for MiniBox openUPS device ( http://www.mini-box.com/OpenUPS) and a dump of the hid usages. I had the possibility to make a few adjustments to the device firmware for HID usages, and although I haven't managed to produce a good structure many issues from previous firmware were at least fixed and new information added. ATM the driver only shows pertaining

Hi Recently i bought a MicroDoWell BP50, and with it followed a USB 2 serial converter. When i plug it into my 2.6.19 kernel, dmesg shows hiddev96: USB HID v1.10 Device [Cyber Power System CPS RS232 USB BRIDGE for UPS] on usb-0000:00:04.2-2 usbcore: registered new interface driver usbhid drivers/usb/input/hid-core.c: v2.6:USB HID core driver So, i figured i should use usbhid-ups,

>> Over the last couple months, we have had a couple incidents (luckily a= ll >> on weekends) where all 15 UPSs will mysteriously shut off, and we had = to >> manually power them back up. To top it off, there was nothing in syslo= g >> about any UPS going onto battery power and staying there - just a coup= le >> curious low-battery warnings from one of the UPSs. You

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:

Since reports received over the interrupt pipeline are a recurring problem for various types of UPS'es, I propose to simply ignore the data we receive there and only flush the respective report buffer. By doing so, at the time the interrupt reports are processed the first variable that is retreived will trigger a poll for the corresponding feature report and we should be fine. The impact on

upsmon.conf using NOTIFCMD and NOTIFYFLG is working well, it is calling my script "notify" on requested events (ONBATTERY,LOWBATTERY and ONLINE). Command #upsmon -c fsd -u monmaster myups at localhost gracefully shutdown my box and after several seconds switch off the ups's load. Two problems: - notify script is called and executed as user "nut" (as it used to be

On Sat, Jun 27, 2020, at 23:11, Manuel Wolfshant wrote: > On 6/28/20 5:54 AM, Scott Colby wrote: >> >> I'm not convinced this is the problem; I think that pfSense has an alternative way of running the NUT components: # ps aux | grep ups root 45456 0.0 0.1 6796 884 - Is 02:22 0:00.01 /usr/local/sbin/upsmon uucp 45751 0.0 0.1 6796 772 - S 02:22

> Author: agordeev-guest > Date: Wed Oct 3 00:09:21 2007 > New Revision: 1136 > > Log: > - drivers/megatec_usb.c: added ability to do subdriver-specific > initialization, and moved some shared code to agiler init function > since krauler doesn't need it. [...] I'm not very thrilled about this patch: 1) Down at the subdriver level, one shouldn't use

Reporting current in milliAmps is not a good idea. This will lead to impractically large values, especially when we report them with two decimals resolution (10 microAmps). Even the laboratory measuring equipment that is standing right next to me now, doesn't offer this resolution in the range that is common for most UPS'es. I think you meant to write 'Ampere (A)' here

'belkin-hid.c' and 'tripplite-hid.c' subdrivers, the only thing that happens when the shutdown functions are run is sending DelayBeforeShutdow= n (if that's available, which it probably always is). According to the HID Power Devices specification, it will do just that and is effectively the same as 'shutdown.stayoff'. If there is mains power at that time, the output

Hi, Arjen; I am new to linux and not sure how to create the PowerCom-usb driver. So could you please compile powercom-usb file for me. I am happy to test it out with the USB PowerCom Ups. Thanks, Paul MCSE/MCSA/MCP ------------------------------ Message: 2 Date: Mon, 03 Sep 2007 11:13:32 +0200 From: Arjen de Korte <nut+users at de-korte.org> Subject: Re: [Nut-upsuser] Powercom USB UPS is

Hi I'm having a problem with the bcmxcp_usb driver FSD command: everything seems to work apart from: upsmon -c fsd Environment: Ubuntu 7.04, nut 2.0.5-1, nut-usb 2.0.5-1, Powerware 3105 UPS. upsd appears to send the FSD command to the UPS, upsmon then runs my NOTIFYCMD (which halts my PC) but the UPS just doesn't turn off. Here are the /var/log/daemon.log entries: Jul 24 23:13:16

Good afternoon all, I have a Tripp-Lite SmartOnline SU1500RTXL2ua UPS that I had previously tried to get up and running with NUT earlier this year. Peter Selinger had been working with this, but he had to devote time to more important things, and I did too, so it got pushed to the back burner. I saw in the release announcement of 2.2 that the UPS is now supported and decided I would try once

Citeren Arjen de Korte <adkorte-guest at alioth.debian.org>: > Author: adkorte-guest > Date: Mon Nov 24 13:13:44 2008 > New Revision: 1578 > > Log: > Use new usb_device_id_t and is_usb_device_supported() > for selection of the subdriver. Alexander, It would be nice if you could double check that I didn't horribly break something here. I don't expect any

Arjen de Korte wrote: > > + * drivers/apc-hid.c: > + - Commented out the 'fullycharged' status. If anyone can explain the > + use of this, please step forward. This flag is defined on p.36 of the "Universal Serial Bus Usage Tables for HID Power Devices", Release 1.0 November 1, 1997, a USB standards document available on the web. The document defines this

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

I've just committed a rough version of the idowell-hid subdriver to the trunk. It is already integrated in the usbhid-ups, but I lack the time to complete the NUT to HID mapping in it. The following message on the nut-upsuser mailinglist should provide enough clues to add most of them: http://lists.alioth.debian.org/pipermail/nut-upsuser/2011-January/006506.html I would be

I've just set up a CyberPower Value 2200E-GP on a system running Lucid AMD64, with the current NUT package via apt-get, and it seems to be working fine for me with the usbhid-ups driver, so I guess it can go in the HCL? I'm using the system to host several virtual servers under KVM, and to make things simple I set it up to hibernate rather than shutdown, that way all the guest OS