<br><div class="gmail_quote">2012/11/21 Walshe, John (DCOR) <span dir="ltr"><<a href="mailto:John.Walshe@smithsdetection.com" target="_blank">John.Walshe@smithsdetection.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div link="blue" vlink="purple" lang="EN-IE"><div><p class="MsoNormal">Hi Folks,<u></u><u></u></p><p class="MsoNormal">I’m trying to use a ZIGOR Danubio 2000 ups with NUT on Debian squeeze (AMD64).<u></u><u></u></p><p class="MsoNormal">
OS/NUT are all the latest official release (as of last week) with NUT installed from packages.<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">As the usb descriptor presents MEC (and the Fry’s electronics) I chose to use the blazer_usb driver.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">All appears to work well excepting that the UPS does not appear to accept the shutdown instcmd to turn off the ups outputs at the end of the shutdown process. The UPS remains on until the batteries completely drain and it has to turn off to protect itself.<u></u><u></u></p>
<p class="MsoNormal">Apart from that, reporting, messaging, shutdown process etc all works well.<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">On shutdown I can see <u></u><u></u></p>
<p class="MsoNormal">instcmd: command [shutdown.stop] handled<u></u><u></u></p><p class="MsoNormal">instcmd: command [shutdown.return] handled<u></u><u></u></p><p class="MsoNormal">Shutting down in 30 seconds<u></u><u></u></p>
<p class="MsoNormal"> Waiting for UPS to cut power.<u></u><u></u></p><p class="MsoNormal">Will now halt.<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">The PC turns off put UPS stays running until batteries run out.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">So I can see that the driver issues the command and thinks that it is “handled”. Looking at it with higher debug level I can see that the driver reports a “USB no ACK” to these instcmds. Checking the USB with wireshark shows that this text string originated in the UPS, ie it is a text string returned in response to the instcmds.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">Looking closer at the USB descriptor it presents MEC0003 rather than the MEC0002 that I see all over the fora.<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">So it would appear that there is a new variety of MEC protocol. <u></u><u></u></p><p class="MsoNormal">Has anyone else seen this?<u></u><u></u></p><p class="MsoNormal">Is there any work ongoing with this MEC0003 protocol?<u></u><u></u></p>
<p class="MsoNormal">What can I do to help this cause? (bear in mind I’m a Linux newbie – but with good backup <span style="font-family:Wingdings">J</span> ) <br></p></div></div></blockquote></div><br clear="all">could you please send back a driver output, debug level 5 (i.e -DDDDD), including a shutdown.return command sent from upscmd.<br>
note that, for this test, you should remove your system from the UPS, or send directly a shutdown.stop afterward.<br><br>I'm also interested in the wireshark snoop.<br><br>cheers,<br>Arnaud<br>-- <br>NUT (Network UPS Tools) Project Leader - <a href="http://www.networkupstools.org" target="_blank">http://www.networkupstools.org</a><br>
Debian Developer - <a href="http://www.debian.org" target="_blank">http://www.debian.org</a><br>Free Software Developer - <a href="http://arnaud.quette.fr" target="_blank">http://arnaud.quette.fr</a><br><br>