Hi Folks, I'm trying to use a ZIGOR Danubio 2000 ups with NUT on Debian squeeze (AMD64). OS/NUT are all the latest official release (as of last week) with NUT installed from packages. As the usb descriptor presents MEC (and the Fry's electronics) I chose to use the blazer_usb driver. 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. Apart from that, reporting, messaging, shutdown process etc all works well. On shutdown I can see instcmd: command [shutdown.stop] handled instcmd: command [shutdown.return] handled Shutting down in 30 seconds Waiting for UPS to cut power. Will now halt. The PC turns off put UPS stays running until batteries run out. 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. Looking closer at the USB descriptor it presents MEC0003 rather than the MEC0002 that I see all over the fora. So it would appear that there is a new variety of MEC protocol. Has anyone else seen this? Is there any work ongoing with this MEC0003 protocol? What can I do to help this cause? (bear in mind I'm a Linux newbie - but with good backup :) ) Le meas, John PROPRIETARY: This e-mail contains proprietary information some or all of which may be legally privileged. It is intended for the recipient only. If an addressing or transmission error has misdirected this e-mail, please notify the authority by replying to this e-mail. If you are not the intended recipient you must not use, disclose, distribute, copy, print, or rely on this e-mail. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20121121/5790743e/attachment.html>
2012/11/21 Walshe, John (DCOR) <John.Walshe at smithsdetection.com>> Hi Folks,**** > > I?m trying to use a ZIGOR Danubio 2000 ups with NUT on Debian squeeze > (AMD64).**** > > OS/NUT are all the latest official release (as of last week) with NUT > installed from packages.**** > > ** ** > > As the usb descriptor presents MEC (and the Fry?s electronics) I chose to > use the blazer_usb driver.**** > > ** ** > > 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.**** > > Apart from that, reporting, messaging, shutdown process etc all works > well.**** > > ** ** > > ** ** > > On shutdown I can see **** > > instcmd: command [shutdown.stop] handled**** > > instcmd: command [shutdown.return] handled**** > > Shutting down in 30 seconds**** > > Waiting for UPS to cut power.**** > > Will now halt.**** > > ** ** > > The PC turns off put UPS stays running until batteries run out.**** > > ** ** > > 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.**** > > ** ** > > Looking closer at the USB descriptor it presents MEC0003 rather than the > MEC0002 that I see all over the fora.**** > > ** ** > > So it would appear that there is a new variety of MEC protocol. **** > > Has anyone else seen this?**** > > Is there any work ongoing with this MEC0003 protocol?**** > > What can I do to help this cause? (bear in mind I?m a Linux newbie ? but > with good backup J ) >could you please send back a driver output, debug level 5 (i.e -DDDDD), including a shutdown.return command sent from upscmd. note that, for this test, you should remove your system from the UPS, or send directly a shutdown.stop afterward. I'm also interested in the wireshark snoop. cheers, Arnaud -- NUT (Network UPS Tools) Project Leader - http://www.networkupstools.org Debian Developer - http://www.debian.org Free Software Developer - http://arnaud.quette.fr -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20121126/f75383cc/attachment-0001.html>
2012/11/27 Walshe, John (DCOR) <John.Walshe at smithsdetection.com>> Hi Arnaud, >Hi John> **** > > Thanks for replying. >welcome, but please keep the list cc'ed!> **** > > Since I sent the message I tried the UPS on winXP just to see if the > upsilon s/w did toggle beeper and shutdown as required. Indeed it did, but > it didn?t perform any of the battery tests . So with UsbSnoop I tried to > grab the usb traffic to capture the command stream. Unfortunately that s/w > doesn?t seem to capture the downstream properly ? just the upstream. From > that however I could see that the reply to the standard query (Q1) command > conformed to the MEC0002 protocol ? so we are not far away.**** > > We presently have the ups on another PC with XP inside a VM on Debian > squeeze. We?ll try to capture the downstream from upsilon that does result > in a shutdown and a beeper toggle.**** > > If we have luck I?ll send you the details.**** > > ** >ok, thanks. considering the above, a blazer_usb trace, with debug level 5 (i.e -DDDDD) would be interesting too. which version of NUT are you using btw? cheers, Arno -- NUT (Network UPS Tools) Project Leader - http://www.networkupstools.org Debian Developer - http://www.debian.org Free Software Developer - http://arnaud.quette.fr -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20121128/6a08b5a8/attachment.html>