Nut upsdev - Nov 2008 - Sweex 1000VA UPS (Lakeview Research)

Hi all,

i've read a thread about this UPS from Peter van Valderen. He tried to
develop a
driver for this specific type of UPS. I've downloaded nut-2.2.2 and tried to
apply
the patches (lakeview.patch & lakeview.v2.patch) but both resulted in
rejected
chunks. I've tried to ./configure with type lakeview and then a make, but
the make
command fails.

 

Does anybody has any experience with getting this type of UPS working with
nut?

In the latest version of nut I don't find any reference to this lakeview
driver.

 

Regards,

 

Tom Cassimon

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20081130/5170c62c/attachment.htm

On Sun, Nov 30, 2008 at 3:18 PM, Tom Cassimon <tom at cassimon.mine.nu>
wrote:
> Hi all,
>
> i've read a thread about this UPS from Peter van Valderen. He tried to
> develop a
> driver for this specific type of UPS. I've downloaded nut-2.2.2 and
tried to
> apply
> the patches (lakeview.patch & lakeview.v2.patch) but both resulted in
> rejected
> chunks. I've tried to ./configure with type lakeview and then a make,
but
> the make
> command fails.
Can you please point us to the patches you are looking at?
> Does anybody has any experience with getting this type of UPS working with
> nut?
>
> In the latest version of nut I don't find any reference to this
lakeview
> driver.
Lakeview Research probably refers to Jan Axelson's consultancy. She
has written at least one book on USB device and driver development,
and the UPS in question may have used the USB Vendor ID for Lakeview
Research.

-- 
- Charles Lepple

On Sun, Nov 30, 2008 at 3:18 PM, Tom Cassimon <tom at cassimon.mine.nu>
wrote:
> Hi all,
>
> i've read a thread about this UPS from Peter van Valderen. He tried to
> develop a
> driver for this specific type of UPS. I've downloaded nut-2.2.2 and
tried to
> apply
> the patches (lakeview.patch & lakeview.v2.patch) but both resulted in
> rejected
> chunks. I've tried to ./configure with type lakeview and then a make,
but
> the make
> command fails.
I finally started reading the old thread about this UPS from 2007.

Kjell pointed out[1] that Richcomm System Technologies Co. Ltd. makes
the USB-to-dry-contact converter that seems to be used here[2].

[1] http://lists.alioth.debian.org/pipermail/nut-upsdev/2007-May/002081.html

[2] http://rstcl7795.en.china.cn/selling-leads/detail,1010408416,.html

Excerpt from that page, in case it moves:

Product Origin:China
Brand Name:Richcomm

Description:
Product Name: USB Convert Inside Solution for Smart/DryContact UPS

Features: 1) Model numbers: (smart) RC-UB-PN100, (dry) RC-UB-PN20 2)
Smart UPS: a) Instantly converts RS232 communication into USB
communication mode b) Works with PowerManager II software, realizing
inquiry to smart UPS status, data and device control under USB
communication mode 3) Dry contact UPS: a) Convert dry-contact smart
communication function into USB communication mode b) Inquires smart
UPS status and shutdown control under USB communication mode with
PowerManager Lite software c) With PowerManagerLite: USB judges
dry-contact signals: battery voltage low and AC power failed under USB
monitoring mode d) With PowerManagerLite: USB can shut down UPS under
USB monitoring mode

Arjen mentioned that sweex_usb might not be a good name[3], because
they keep changing hardware in their devices.

[3] http://lists.alioth.debian.org/pipermail/nut-upsdev/2007-May/002079.html

How about richcomm_usb, as suggested by Peter Selinger? [4] It sounds
like they make both the converter device and the Windows driver.

[4] http://lists.alioth.debian.org/pipermail/nut-upsdev/2007-May/002094.html

-- 
- Charles Lepple

I updated my driver to work with nut 2.2.2 six months ago, you can
find it here: http://ddcrew.com/lakeview-2.2.2.patch

It works just fine for me. It was never included because it doesn't
conform to some part of NUT's coding standard, something regarding USB
if I'm not mistaken. I do not have the time nor do I care enough to
rewrite the driver in the near future or probably ever, so this patch
is probably your only bet of getting it working.

Good luck!

Best regards,

Peter van Valderen

Citeren Peter van Valderen <dosperios at gmail.com>:
> I was not aware that it had been imported into the trunk. Last time I
> looked noone seemed to have done anything with the driver or have any
> interest, so I figured there was no point. If there's any real
> interest in keeping it in the trunk, I can have a look with my device
> to see if I have the same problem mentioned above. If so, it should
> probably be fixable pretty easily.
In addition to the issues already mentioned, there are some others  
(maybe not so easy to fix):

1) It is not allowed to call upsdrv_initups() in the reconnect  
function. In upsdrv_initups() one should exit() from the driver if the  
UPS is not found. However, once you have reached upsdrv_updateinfo()  
the driver must not exit() if the UPS isn't found, but rather attempt  
to reconnect forever.

2) Similar to the above, the behavior of (re)connecting to the UPS  
must be different in upsdrv_initups() and upsdrv_updateinfo(). In the  
first case, one would probably retry several times (32 now) before  
deciding the UPS isn't there. In the latter case, the driver should  
attempt only once for each call to upsdrv_updateinfo() and return  
immediately if things don't work out. You don't have time to do  
repeated attempts here, otherwise the server will not hear from the  
driver too long.

3) Similar to the above, reading garbage data should be limited to  
once per pass upon reconnecting, like the below rudimentary example:

#define IGNORE_QUERY	5

static int	ignore = 0;

[...]

void upsdrv_updateinfo(void)
{
	char	reply[REPLY_PACKETSIZE];
	int	ret;

	if ((ignore == IGNORE_QUERY) && (reconnect() != SUCCESS)) {
		usb_comm_fail("Reconnecting to UPS failed");
		return;
	}

	ret = query_ups(reply);

	if (ret < 4) {
		usb_comm_fail("Query to UPS failed");
		dstate_datastale();
		ignore = IGNORE_QUERY;
		return;
	}

	usb_comm_good();
	dstate_dataok();

	if (ignore > 0) {
		ignore--;
		return;
	}

	[...]

4) Don't use upslog*() too often. System administrators don't like it  
if their syslog is spammed with information that is for debugging  
purposes only.

5) For the usb_control_msg() and usb_interrupt_read() calls, make a  
difference between error (ret < 0) and timeout (ret == 0), like in the  
following example:

	ret = usb_control_msg(upsdev, STATUS_REQUESTTYPE, REQUEST_VALUE,
		MESSAGE_VALUE, INDEX_VALUE, query, sizeof(query), 1000);

	if (ret < 0) {
		upsdebug_with_errno(3, "send");
		return ret;
	}

	if (ret == 0) {
		upsdebugx(3, "send: timeout");
		return ret;
	}

	upsdebug_hex(3, "send", query, ret);

Similarly, you would do the same after the usb_interrupt_read() call.  
This will help in diagnosing communication problems should this ever  
be needed.

6) Watch out with sleep() in the driver. With a timeout value of 1  
second in the usb_* calls, adding another 3 seconds will already bring  
you dangerously close to the five (5) seconds that are allowed in  
upsdrv_updateinfo().

Best regards, Arjen
-- 
Please keep list traffic on the list