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
Peter van Valderen
2008-Dec-16 11:59 UTC
[Nut-upsdev] Sweex 1000VA UPS (Lakeview Research)
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