similar to: ALARM words

Hello all, In my new driver I have a function that searches for the position of a known substring in a delimited string. I am trying to populate a series of integer variables with the position value of various substrings. The first call to the function performs correctly but the remaining calls in the code series are not being executed (there are six more calls after the first successful

Do your drivers/Makefile.am rules for the resulting new program specify dependencies to use similar to other USB-capable drivers? e.g. ```` blazer_usb_SOURCES = blazer.c blazer_usb.c $(LIBUSB_IMPL) usb-common.c blazer_usb_LDADD = $(LDADD_DRIVERS) $(LIBUSB_LIBS) -lm ```` Jim On Sat, Nov 2, 2024 at 2:30?AM William R. Elliot <bill at wreassoc.com> wrote: > Hello again all. > > I am

Hello, always nice to hear about new drivers :) OTOH, check for any variables you might have been re-using, so their earlier state impacts later runs - whether buffers allocated statically (or by caller without rewinding the pointer and maybe nulling the contents), or position counters, etc. Similarly, be sure to pre-initialize anything of value and not start out with random bits from the stack.

Hello again all. I am trying to use USB functions (non-HID) and I get a linker error for functions that are in the included usb-common.h file. Specifically, at the start, these functions: - warn_if_bad_usb_port_filename - nutusb_open - is_usb_device_supported Clearly the headers are there or I don't think the driver would compile. Can someone point me in the right direction please? Thank

Regarding the follow-up, IIRC `open` walks a device list returned by libusb, checks each entry against the matcher, and tells libusb if it wants to claim the device described by a particular entry. I don't think it walks further entries after a successful match and claim? We can't use the matcher directly, because its fields can be a regex geberally (e.g. `vendor=A*` instead of `APC` or

Sounds great! By `connection error` it looks like the `upsc` client had nowhere to go. Is `upsd` started (and does it `LISTEN` on locahost or asterisk per `upsd.conf`)? Jim On Sat, Oct 26, 2024, 08:13 William R. Elliot <bill at wreassoc.com> wrote: > Hello again. > > I now have large chunks of the new driver working in the foreground and > wanted to see what upsc reports

Thinking of it, we can't conjure a libusb descriptor from thin air because the library can have internal state associated with it (allocated buffers, open-close count, etc.) On Tue, Nov 26, 2024, 21:06 Jim Klimov <jimklimov+nut at gmail.com> wrote: > Regarding the follow-up, IIRC `open` walks a device list returned by > libusb, checks each entry against the matcher, and tells

An HTML attachment was scrubbed... URL: <http://alioth-lists.debian.net/pipermail/nut-upsdev/attachments/20241022/a5e3106d/attachment.htm>

The ups I am working on implemented their serial protocol over USB. Is it possible to implement a single driver that would talk over either serial or USB depending on what was found...or how ups.conf is setup? Or is it "far" better to have a single serial driver and a single USB driver that share the common ups protocol stuff in a third file? Thanks, Bill -- This email has been

Hello all. Implementation is serial protocol over USB (hey, it is what it is). I am able to find the device (regex) and open it, send it a command and get a response. The problem is that I see all of the transactions in my USB sniffing tool (8-byte chunks) but the buffer that is used for the response in 'get_interrupt' is missing one or more of the beginning chunks (using printf

Hi Billy, switching back this thread to -upsdev 2012/2/27 William R. Elliot <bill at wreassoc.com>: > I have been able to set the 'FSD' from the driver and it is picked up by > upsmon.? That gives me the functionality that I was asked to put in the > driver.? If that is against the rules then I'll make an adjustment when the > allowed method is defined.? :-) yup,

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

An HTML attachment was scrubbed... URL: <http://alioth-lists.debian.net/pipermail/nut-upsdev/attachments/20241024/4b16b621/attachment.htm>

An HTML attachment was scrubbed... URL: <http://alioth-lists.debian.net/pipermail/nut-upsdev/attachments/20241026/ce542852/attachment.htm>

An HTML attachment was scrubbed... URL: <http://alioth-lists.debian.net/pipermail/nut-upsdev/attachments/20241125/2f581c92/attachment.htm>

The list of status bits we're seeing has increased over the years. Currently for instance, the usbhid-ups driver has defined no less than 20 status bits (and I intend to add two more in the next couple of days, FRANGE and FANFAIL): #define STATUS_ONLINE 0x00001 /* on line */ #define STATUS_DISCHRG 0x00002 /* discharging */ #define STATUS_CHRG 0x00004 /*

Hello up there! Attached is my patch to add support for AL175 alarm module, Please ACK or NAK this. -- ?????? ??????? -------------- next part -------------- A non-text attachment was scrubbed... Name: al175.patch Type: text/x-diff Size: 35632 bytes Desc: not available Url : http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20050919/84b639e0/al175-0001.bin

2012/2/28 Arnaud Quette <aquette.dev at gmail.com>: > Hi Charles > > 2012/2/28 Charles Lepple <clepple at gmail.com>: >> On Feb 28, 2012, at 3:44 AM, Arnaud Quette wrote: >> >>> Hi Billy, >>> >>> switching back this thread to -upsdev >>> >>> 2012/2/27 William R. Elliot <bill at wreassoc.com>: >>>> I

Hi, Ok, I put the new TE410 into our system last night - This is the second TE410P card. There is also TDM400P in Slot 5 with IRQ 9 which is shared with aic7xxx (SCSI) According to "cat /proc/interrupts", the new card is in the second slot using IRQ 11 (the first card is in slot 1 on IRQ 10 - but always has been). With only the original card install, there has been no issues with

Check with your telco. We had the same problem on 1 of our PRI's, every day at 5:00 sharp, red alarm, with all calls cut off for 30 seconds exactly. Turns out the equipment at the CO was going into a test loop at that time because of a forgotten setting by a tech. Man, what a finger pointing exercise that was. -----Original Message----- From: Matthew Boehm [mailto:mboehm@cytelcom.com] Sent: