Hi, I'm not the maintainter for the "megatec_usb" driver (in fact, I'm no longer maintainer for the base "megatec" either), so I don't really know the status for that particular UPS. I'm forwarding this to the NUT mailing-list though. Regards, -- Carlos Rodrigues On Fri, Dec 5, 2008 at 10:30 AM, Adrian Czerniak <adrian.czerniak at becomo.com> wrote:> Hi, > > are you going to support Mustek PowerMust 848? I'm not able to run it with > lastest SVN: > > #./megatec_usb -a mustek -DDDDD > Network UPS Tools 2.3.0-1595 - Megatec protocol driver 1.5.18 [megatec_usb] > Carlos Rodrigues (c) 2003-2008 > > Serial-over-USB transport layer for Megatec protocol driver [megatec_usb] > Andrey Lelikov (c) 2006, Alexander Gordeev (c) 2006-2007, Jon Gough (c) 2007 > > debug level is '5' > Checking device (0665/5161) (003/004) > - VendorID: 0665 > - ProductID: 5161 > - Manufacturer: Cypress Semiconductor > - Product: USB to Serial > - Serial Number: unknown > - Bus: 003 > Trying to match device > Device matches > DTR=1, RTS=0 > send_to_all: SETINFO driver.version.internal "1.5.18" > Starting UPS detection process... > Asking for UPS information [I]... > I => FAILED [short read] > I detail: (1 bytes) => 49 > Asking for UPS status [Q1]... > 00]_data_phoenix: got so far [Q1 > get_data_phoenix: (8 bytes) => 51 31 0d 2e 30 0d 30 30 > Q1 => FAILED [short read] > Q1 detail: (2 bytes) => 51 31 > Asking for UPS status [Q1]... > 00]_data_phoenix: got so far [Q1 > get_data_phoenix: (8 bytes) => 51 31 0d 2e 30 0d 30 30 > Q1 => FAILED [short read] > Q1 detail: (2 bytes) => 51 31 > Asking for UPS status [Q1]... > 00]_data_phoenix: got so far [Q1 > get_data_phoenix: (8 bytes) => 51 31 0d 2e 30 0d 30 30 > Q1 => FAILED [short read] > Q1 detail: (2 bytes) => 51 31 > Asking for UPS status [Q1]... > 00]_data_phoenix: got so far [Q1 > get_data_phoenix: (8 bytes) => 51 31 0d 2e 30 0d 30 30 > Q1 => FAILED [short read] > Q1 detail: (2 bytes) => 51 31 > Asking for UPS status [Q1]... > 00]_data_phoenix: got so far [Q1 > get_data_phoenix: (8 bytes) => 51 31 0d 2e 30 0d 30 30 > Q1 => FAILED [short read] > Q1 detail: (2 bytes) => 51 31 > 5 out of 5 detection attempts failed (minimum failures: 2). > Megatec protocol UPS not detected. > > -- > Regards, > Adrian Czerniak > >
Citeren Carlos Rodrigues <cefrodrigues at gmail.com>: [...]>> Starting UPS detection process... >> Asking for UPS information [I]... >> I => FAILED [short read] >> I detail: (1 bytes) => 49This is not uncommon, many UPSes speaking Megatec protocol don't implement this, so I'm not too worried about this reply.>> Asking for UPS status [Q1]... >> 00]_data_phoenix: got so far [Q1 >> get_data_phoenix: (8 bytes) => 51 31 0d 2e 30 0d 30 30 >> Q1 => FAILED [short read] >> Q1 detail: (2 bytes) => 51 31But this is odd. It echos the Q1 query straight back at us. So the communication seems to be fine, but the UPS doesn't support this command. So either 1) The UPS is implementing a *very* old version of the Megatec protocol and uses the 'D' command to query for status information (this was obsolete back in 1996 already). Please try if changing line 426 from ser_send_pace(upsfd, SEND_PACE, "Q1%c", ENDCHAR); to ser_send_pace(upsfd, SEND_PACE, "D%c", ENDCHAR); will get us an answer from the UPS. Most likely, we won't be able to parse the reply, but for the moment we just want it to talk to us. Make sure you run it in -DDDDD debug mode. 2) It doesn't use the Megatec protocol. In that case, you'll have to use 'usbsnoop' (search Google) while running it with the (bundled?) Windows software to see if we can figure out if this is a familiar protocol or that we need something completely new. In any case, we'll take this to the development mailinglist. Please answer there. Best regards, Arjen -- Please keep list traffic on the list
On Sun, 07 Dec 2008 09:31:23 +0100, Arjen de Korte wrote> Citeren Carlos Rodrigues <cefrodrigues at gmail.com>: > > [...] > > >> Starting UPS detection process... > >> Asking for UPS information [I]... > >> I => FAILED [short read] > >> I detail: (1 bytes) => 49 > > This is not uncommon, many UPSes speaking Megatec protocol don't > implement this, so I'm not too worried about this reply. > > >> Asking for UPS status [Q1]... > >> 00]_data_phoenix: got so far [Q1 > >> get_data_phoenix: (8 bytes) => 51 31 0d 2e 30 0d 30 30 > >> Q1 => FAILED [short read] > >> Q1 detail: (2 bytes) => 51 31 > > But this is odd. It echos the Q1 query straight back at us. So the > communication seems to be fine, but the UPS doesn't support this > command. So either > > 1) The UPS is implementing a *very* old version of the Megatec > protocol and uses the 'D' command to query for status information > > (this was obsolete back in 1996 already). Please try if changing > line 426 from > > ser_send_pace(upsfd, SEND_PACE, "Q1%c", ENDCHAR); > to > ser_send_pace(upsfd, SEND_PACE, "D%c", ENDCHAR); > > will get us an answer from the UPS. Most likely, we won't be able to > parse the reply, but for the moment we just want it to talk to us. > Make sure you run it in -DDDDD debug mode. > > 2) It doesn't use the Megatec protocol. In that case, you'll have to > use 'usbsnoop' (search Google) while running it with the (bundled?) > Windows software to see if we can figure out if this is a familiar > protocol or that we need something completely new. > > In any case, we'll take this to the development mailinglist. Please > answer there. >Unfortunately, suggested change in source code doen't seem to fix anything: sudo ./megatec_usb -a mustek -DDDDD Network UPS Tools 2.3.0-1603M - Megatec protocol driver 1.5.18 [megatec_usb] Carlos Rodrigues (c) 2003-2008 Serial-over-USB transport layer for Megatec protocol driver [megatec_usb] Andrey Lelikov (c) 2006, Alexander Gordeev (c) 2006-2007, Jon Gough (c) 2007 debug level is '5' Checking device (0665/5161) (003/004) - VendorID: 0665 - ProductID: 5161 - Manufacturer: Cypress Semiconductor - Product: USB to Serial - Serial Number: unknown - Bus: 003 Trying to match device Device matches DTR=1, RTS=0 send_to_all: SETINFO driver.version.internal "1.5.18" Starting UPS detection process... Asking for UPS information [I]... I => FAILED [short read] I detail: (1 bytes) => 49 Asking for UPS status [Q1]... get_data_phoenix: got so far [f] get_data_phoenix: (8 bytes) => 66 1c 00 2e 30 0d 30 30 Q1 => FAILED [short read] Q1 detail: (4 bytes) => 66 1c 2e 30 Asking for UPS status [Q1]... get_data_phoenix: got so far [f] get_data_phoenix: (8 bytes) => 66 1c 00 2e 30 0d 30 30 Q1 => FAILED [short read] Q1 detail: (4 bytes) => 66 1c 2e 30 Asking for UPS status [Q1]... get_data_phoenix: got so far [f] get_data_phoenix: (8 bytes) => 66 1c 00 2e 30 0d 30 30 Q1 => FAILED [short read] Q1 detail: (4 bytes) => 66 1c 2e 30 Asking for UPS status [Q1]... get_data_phoenix: got so far [f] get_data_phoenix: (8 bytes) => 66 1c 00 2e 30 0d 30 30 Q1 => FAILED [short read] Q1 detail: (4 bytes) => 66 1c 2e 30 Asking for UPS status [Q1]... get_data_phoenix: got so far [f] get_data_phoenix: (8 bytes) => 66 1c 00 2e 30 0d 30 30 Q1 => FAILED [short read] Q1 detail: (4 bytes) => 66 1c 2e 30 5 out of 5 detection attempts failed (minimum failures: 2). Megatec protocol UPS not detected. -- Regards, Adrian Czerniak