search for: ser_get_lin

I recently bought a Belkin F6H375 UPS. It connects to the computer via USB. Searching the Internet led me to believe that the megatec_usb driver in nut supports this UPS, however I've been unable to get it to work. I have this in ups.conf: [belkinusb] driver = megatec_usb port = auto desc = "Belkin USB" Here's what happens when I try to use it: ~ #

..., Ltd". The current SVN version of NUT does not work with this device. The megatec_usb driver can't get a proper reply to a Q1 request, failing with an error message about "short read (14 bytes)" instead. I have found the reason for this. The function run_query in megatec.c uses ser_get_line to get information from the UPS. The ser_get_line function has an "endchar" parameter, and "\r" is currently passed there. As a result, ser_get_line only returns the received characters up to the first "\r" (hex 0d) back to run_query. The problem is, the data returne...

...fatalx(EXIT_FAILURE, "Unable to detect a Best/SOLA or Phoenix protocol UPS"); @@ -333,7 +333,7 @@ void upsdrv_updateinfo(void) } /* these things need a long time to respond completely */ - usleep(200000); + struct timespec delay = {0, 200e6}; nanosleep(&delay, NULL); ret = ser_get_line(upsfd, buf, sizeof(buf), ENDCHAR, "", SER_WAIT_SEC, SER_WAIT_USEC); Index: b/drivers/microdowell.c =================================================================== --- a/drivers/microdowell.c 2011-08-17 00:40:17.000000000 +0300 +++ b/drivers/microdowell.c 2011-08-17 00:40:17.00000...

Citeren Arjen de Korte <adkorte-guest at alioth.debian.org>: > Author: adkorte-guest > Date: Wed Nov 5 07:56:47 2008 > New Revision: 1549 > > Log: > Fix problem with reading replies on slow systems. > > The ser_get_line() function is unreliable when reading multi-line > replies from the UPS. See > docs/new-drivers.txt for an explanation why. Basically this will > only work if the driver is able > to keep up with the flow of data from the UPS and the select_read() > function in ser_get_line()...

I have an UPS, that claims to be IPPon Back Power Pro 700. I'm trying to connect it using USB. lsusb -v says: Bus 1 Device 3: ID 06da:0003 Phoenixtec Power Co., Ltd Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 1.10 bDeviceClass 0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0

...or USB to Serial Permissions are OK: # ls -l /dev/bus/usb/006/007 crw-rw-r-- 1 root nut 189, 646 ago 8 01:51 /dev/bus/usb/006/007 But the driver does not get it: # /lib/nut/megatec_usb -a yukai -u root Network UPS Tools - Megatec protocol driver 1.6 (2.4.3) Serial-over-USB transport layer 0.10 ser_get_line: Device detached? (error -1: No error) Successfully reconnected ser_get_line: Device detached? (error -1: No error) Successfully reconnected ser_get_line: Device detached? (error -1: No error) Successfully reconnected Megatec protocol UPS not detected. (that lasted several minutes) USB info of t...

...ler, 0, 20); ? ????????ser_send(upsfd, cmd); +???????sleep(UPSDELAY); ? ????????/* delete command echo up to \012 but no further */ ????????for (ch = '\0'; ch != '\012'; ser_get_char(upsfd, &ch, 0, 10)); ? +???????sleep(UPSDELAY); ????????/* get command response?*/ ????????ret = ser_get_line(upsfd, result, resultsize, '\015', "\012", 3, 0); ? @@ -741,7 +744,9 @@ ????????????????exit(EXIT_FAILURE); ????????} ? +???????sleep(UPSDELAY); ????????execute("fc\r", rstring, sizeof(rstring)); +???????sleep(UPSDELAY); ????????if (strlen(rstring) < 80 ) { ?????????...

...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 ser_get_line() anymore, but usb->get_interrupt() instead or alternatively, get_data_agiler(). Hopping back-and-forth between various layers in the code is bad coding style as it makes the code difficult to understand. 2) So what is the benefit of this patch? It seem to try to optimize something away that c...

...3). test the driver: # /lib/nut/upsdrvctl -u root -D start orvaldi Network UPS Tools - UPS driver controller 2.4.3 0.000000 Starting UPS: orvaldi Network UPS Tools - Megatec protocol driver 1.6 (2.4.3) Serial-over-USB transport layer 0.10 45.000128 Startup timer elapsed, continuing... ser_get_line: Device detached? (error -1: Connection timed out) Successfully reconnected ser_get_line: Device detached? (error -1: Connection timed out) Successfully reconnected ser_get_line: Device detached? (error -1: Connection timed out) Successfully reconnected Megatec protocol UPS not detected. in dmesg...

...s. For the ser_get_char() and ser_get_buf_len() we might do this by changing the return value. For the first, return value -1 would be an error, 0 a timeout and 1 success. The latter could return -1 on error, between 0 and (buflen-1) for a timeout and buflen for success. Unfortunately, the ser_get_line_alert() and ser_get_line() functions don't have a fixed number of bytes (this is determined by the endchar). So we can no longer check if an endchar was received. Bad idea. I'd prefer to add a couple of upsdebug statements in the serial.c library instead. This would leave the inte...

...e_pct(float battvolt) { float value; @@ -178,15 +173,14 @@ return value * 100; } - static int check_ups(void) { char buffer[RECV_BUFFER_LEN]; int ret; upsdebugx(2, "Sending \"F\" command..."); - ser_send_pace(upsfd, SEND_PACE, "F%c", ENDCHAR); - ret = ser_get_line(upsfd, buffer, RECV_BUFFER_LEN, ENDCHAR, IGNCHARS, READ_TIMEOUT, 0); + comm->send("F%c", ENDCHAR); + ret = comm->recv(buffer, RECV_BUFFER_LEN, ENDCHAR, IGNCHARS); if (ret < F_CMD_REPLY_LEN) { upsdebugx(2, "Wrong answer to \"F\" command."); @@ -195,8 +1...

Sorry for a bit longer delay than I anticipated, I was stuffed with the work. This is the next iteration of the patch adding some functionality to apcsmart driver, and relying on 'ignorelb' recently added. Follow up from previous thread: http://www.mail-archive.com/nut-upsdev at lists.alioth.debian.org/msg02331.html Main differences is that V3 is split into many small patches, so the

I have an old (1997) Best Ferrups (model FE18KVA) that I am trying to monitor for the first time, but all the Best drivers fail to communicate with it. In ups_sync() in bestuferrups.c and bestfcom.c, the "time" command is sent and a one-line response is read. However, on my UPS, that command returns the current time and then prompts for a new time setting. I worked around that by just

...battery, interval [19.4V, 27.4V]. Done setting up the UPS. # /lib/nut/megatec_usb -D -a belkin Network UPS Tools - Megatec protocol driver 1.6 (2.4.3) Serial-over-USB transport layer 0.10 0.000000 debug level is '1' 32.427474 Starting UPS detection process... 75.263380 ser_get_line: Device detached? (error -1: error sending control message: Operation not permitted) 75.646279 Successfully reconnected 118.177387 ser_get_line: Device detached? (error -1: error sending control message: Operation not permitted) 118.562286 Successfully reconnected 161.087388 s...

...me error and ups (IPPON Smart Power Pro 1400. usb interface) isn't monitoring now [ippon] driver = megatec_usb port = auto desc = "local" Feb 16 23:22:09 f37 upsd[17150]: Instant command: stlk at 127.0.0.1 did test.battery.start on ippon Feb 16 23:22:12 f37 megatec_usb[17249]: ser_get_line: Device detached? (error -1: Unknown error) Feb 16 23:22:12 f37 megatec_usb[17249]: Reconnecting to UPS failed; will retry later... Feb 16 23:22:12 f37 megatec_usb[17249]: Battery test started. Feb 16 23:22:12 f37 megatec_usb[17249]: Reconnecting to UPS failed; will retry later... Feb 16 23:22:...

...bit); +} + void upsdrv_initinfo(void) { int modelnum, i, ret; char temp[256], model[32], *raw; + if (testvar("powercom")) { + set_powercom_lines(); +// straced from powercom's upsmon (reset?) + ret = ser_send(upsfd, "%c%c%c%c%c\r", 1, 2, 2, 3, 5); + ret = ser_get_line(upsfd, temp, sizeof(temp), ENDCHAR, "", + SER_WAIT_SEC, SER_WAIT_USEC); + } raw = get_id(); if (!raw) @@ -426,6 +445,7 @@ void upsdrv_help(void) void upsdrv_makevartable(void) { addvar(VAR_VALUE, "lowbattvolt", "Set low battery level, in volts"); + addvar(...

...uires casting to an unsigned char. > > Modified: > trunk/ChangeLog > trunk/common/common.c > trunk/include/common.h > > Modified: trunk/ChangeLog I would like to do something similar to the following ser_* functions: ser_send_buf ser_send_buf_pace ser_get_buf_len ser_get_line_alert ser_get_line Many drivers currently 'suffer' from compiler signedness warnings. We could do away with these by typecasting everything to the 'correct' type, but I think this is unwanted (and sometimes even counter productive). There is not much point in making explicit that...

...delay, ENDCHAR); > } > > > *************** > *** 581,589 **** > */ > > if (strcasecmp(cmdname, "test.battery.start.deep") == 0) { > ! ser_send_pace(upsfd, SEND_PACE, "TL%c", ENDCHAR); > > ! if (ser_get_line(upsfd, buffer, RECV_BUFFER_LEN, > ENDCHAR, IGNCHARS, READ_TIMEOUT, 0) > 0) { > upslogx(LOG_NOTICE, "test.battery.start.deep > not supported by UPS."); > } else { > upslogx(LOG_INFO, "Deep battery...

This patch introduces a handful of new options, I mentioned earlier in: http://www.mail-archive.com/nut-upsdev at lists.alioth.debian.org/msg02088.html See the large commit message in the follow-up for the details and rationale. I realize it's a bit larger diff - so if it's required I can split it into few smaller ones. Michal Soltys (1): APC smart driver update and new features.

...l-level handshaking to a minimum, you can easily disconnect the cable and reconnect it without complicated resynchronization logic. > What format should all responses by the UPS take so that parsing them is easiest in NUT? Bracketed by tags of some kind? Or is ending with a ?\n? enough? The ser_get_line() function is flexible enough to handle various line endings: http://www.networkupstools.org/docs/developer-guide.chunked/ar01s04.html#_serial_port_handling > Any general suggestions or comments about serial port communication with UPSes? I don?t want to reinvent the wheel here, or leave out...