Александр Безруков
2013-Aug-11 15:25 UTC
[Nut-upsuser] N-Power MEV-3000LT compatibility report and problem
Hello list, first of all, I'd like to report that my UPS N-Power MEV-3000LT (http://www.380v.ru/catalogue/micro-ups/mega-vision , in Russian), which is not in the hardware compatibility list, is mostly supported by the blazer_ser driver. I have very strong grounds to believe that this (and other) N-Power UPS'es are rebranded for Russian and Italian markets from their counterparts produced by Powerbank Electronics Corporation in Taiwan (http://www.powerbank.com.tw/products.php?cat=65&lang=en). I believe they are the same not only because they look the same, have the same specifications etc but also because being in Taipei first I wanted to buy a Powerbank UPS and they told me that they obliged not to sell these UPSes in Taiwan and sent me to Moscow to N-Power, suggesting to buy from them. So I believe the compatibility list deserves two new lines. Now what doesn't work. 1. Shutdown ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ # /lib64/nut/blazer_ser -amv -k -DDD Network UPS Tools - Megatec/Q1 protocol serial driver 1.55 (2.6.5-Unversioned directory) ?? 0.000000??? debug level is '3' ?? 0.108370??? Initiating UPS shutdown ?? 0.108561??? send: 'C' ?? 0.150967??? read: 'NAK' ?? 0.151021??? instcmd: command [shutdown.stop] failed ?? 0.151162??? send: 'C' ?? 0.193506??? read: 'NAK' ?? 0.193598??? instcmd: command [shutdown.stop] failed ?? 0.193725??? send: 'C' ?? 0.236016??? read: 'NAK' ?? 0.236093??? instcmd: command [shutdown.stop] failed ?? 0.236127??? Shutdown failed! Probably the 'C' command has some unlocking mechanism. I remember around 15 years ago I had a cheap Ippon UPS which spoke the same protocol. This UPS fed a Windows PC and had the following problem: during Windows boot-up, when Windows started their own (that time, non-standard) COM-port plug-n-play enumeration of devices, the UPS with a small probability perceived this sequence as 'C' (or 'T', if I still remember right the protocol) and after 30 second switched off the computer being boot. I had to reverse engineer the program is this UPS and discovered commands to lock/unlock shutdown commands which solved the problem. Probably a similar mechanism is implemented in this my UPS but shutdown commands are locked by default. I do not insist on this version, I just want to share this idea. Maybe this is a known problem, then I would appreciate any pointer to find the solution. 2. Reporting battery.runtime and battery.charge. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ I am not sure this has to do with the support of this very specie, likely this is rather a bug in the driver or in the documentation. With this bare configuration: [mv] ??????? driver = blazer_ser ??????? port = /dev/ttyS0 ??????? desc = "N-Power MegaVision 3000LT" and with a fully charged battery the driver reports the following variables: battery.charge: 100 battery.voltage: 109.44 battery.voltage.high: 104.00 battery.voltage.low: 83.20 battery.voltage.nominal: 96.0 device.type: ups driver.name: blazer_ser driver.parameter.pollinterval: 2 driver.parameter.port: /dev/ttyS0 driver.version: 2.6.5-Unversioned directory driver.version.internal: 1.55 input.current.nominal: 13.0 input.frequency: 50.1 input.frequency.nominal: 50 input.voltage: 209.8 input.voltage.fault: 225.1 input.voltage.nominal: 230 output.voltage: 230.7 ups.beeper.status: enabled ups.delay.shutdown: 30 ups.delay.start: 180 ups.load: 15 ups.status: OL ups.temperature: 41.5 ups.type: online Now I would elaborate the config and make use of the runtime guestimation. I added the following lines: runtimecal = 2000,100,5000,50 chargetime = 86400 default.battery.voltage.high = 109.6 default.battery.voltage.low = 84.4 default.battery.capacity = 40 I didn't do any measuerements yet and these data are based solely on the datasheet of my batteries and common sense. Now I get battery.capacity: 40 battery.charge: 0 battery.runtime: 1 battery.voltage: 109.44 battery.voltage.high: 109.6 battery.voltage.low: 84.4 battery.voltage.nominal: 96.0 ... Hello list, first of all, I'd like to report that my UPS N-Power MEV-3000LT (http://www.380v.ru/catalogue/micro-ups/mega-vision , in Russian), which is not in the hardware compatibility list, is mostly supported by the blazer_ser driver. I have very strong grounds to believe that this (and other) N-Power UPS'es are rebranded for Russian and Italian markets from their counterparts produced by Powerbank Electronics Corporation in Taiwan (http://www.powerbank.com.tw/products.php?cat=65&lang=en). I believe they are the same not only because they look the same, have the same specifications etc but also because being in Taipei first I wanted to buy a Powerbank UPS and they told me that they obliged not to sell these UPSes in Taiwan and sent me to Moscow to N-Power, suggesting to buy from them. So I believe the compatibility list deserves two new lines. Now what doesn't work. 1. Shutdown ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ # /lib64/nut/blazer_ser -amv -k -DDD Network UPS Tools - Megatec/Q1 protocol serial driver 1.55 (2.6.5-Unversioned directory) ?? 0.000000??? debug level is '3' ?? 0.108370??? Initiating UPS shutdown ?? 0.108561??? send: 'C' ?? 0.150967??? read: 'NAK' ?? 0.151021??? instcmd: command [shutdown.stop] failed ?? 0.151162??? send: 'C' ?? 0.193506??? read: 'NAK' ?? 0.193598??? instcmd: command [shutdown.stop] failed ?? 0.193725??? send: 'C' ?? 0.236016??? read: 'NAK' ?? 0.236093??? instcmd: command [shutdown.stop] failed ?? 0.236127??? Shutdown failed! Probably the 'C' command has some unlocking mechanism. I remember around 15 years ago I had a cheap Ippon UPS which spoke the same protocol. This UPS fed a Windows PC and had the following problem: during Windows boot-up, when Windows started their own (that time, non-standard) COM-port plug-n-play enumeration of devices, the UPS with a small probability perceived this sequence as 'C' (or 'T', if I still remember right the protocol) and after 30 second switched off the computer being boot. I had to reverse engineer the program is this UPS and discovered commands to lock/unlock shutdown commands which solved the problem. Probably a similar mechanism is implemented in this my UPS but shutdown commands are locked by default. I do not insist on this version, I just want to share this idea. Maybe this is a known problem, then I would appreciate any pointer to find the solution. 2. Reporting battery.runtime and battery.charge. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ I am not sure this has to do with the support of this very specie, likely this is rather a bug in the driver or in the documentation. With this bare configuration: [mv] ??????? driver = blazer_ser ??????? port = /dev/ttyS0 ??????? desc = "N-Power MegaVision 3000LT" and with a fully charged battery the driver reports the following variables: battery.charge: 100 battery.voltage: 109.44 battery.voltage.high: 104.00 battery.voltage.low: 83.20 battery.voltage.nominal: 96.0 device.type: ups driver.name: blazer_ser driver.parameter.pollinterval: 2 driver.parameter.port: /dev/ttyS0 driver.version: 2.6.5-Unversioned directory driver.version.internal: 1.55 input.current.nominal: 13.0 input.frequency: 50.1 input.frequency.nominal: 50 input.voltage: 209.8 input.voltage.fault: 225.1 input.voltage.nominal: 230 output.voltage: 230.7 ups.beeper.status: enabled ups.delay.shutdown: 30 ups.delay.start: 180 ups.load: 15 ups.status: OL ups.temperature: 41.5 ups.type: online Now I would elaborate the config and make use of the runtime guestimation. I added the following lines: runtimecal = 2000,100,5000,50 chargetime = 86400 default.battery.voltage.high = 109.6 default.battery.voltage.low = 84.4 default.battery.capacity = 40 I didn't do any measuerements yet and these data are based solely on the datasheet of my batteries and common sense. Now I get battery.capacity: 40 battery.charge: 0 battery.runtime: 1 battery.voltage: 109.44 battery.voltage.high: 109.6 battery.voltage.low: 84.4 battery.voltage.nominal: 96.0 Hello list, first of all, I'd like to report that my UPS N-Power MEV-3000LT (http://www.380v.ru/catalogue/micro-ups/mega-vision , in Russian), which is not in the hardware compatibility list, is mostly supported by the blazer_ser driver. I have very strong grounds to believe that this (and other) N-Power UPS'es are rebranded for Russian and Italian markets from their counterparts produced by Powerbank Electronics Corporation in Taiwan (http://www.powerbank.com.tw/products.php?cat=65&lang=en). I believe they are the same not only because they look the same, have the same specifications etc but also because being in Taipei first I wanted to buy a Powerbank UPS and they told me that they obliged not to sell these UPSes in Taiwan and sent me to Moscow to N-Power, suggesting to buy from them. So I believe the compatibility list deserves two new lines. Now what doesn't work. 1. Shutdown ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ # /lib64/nut/blazer_ser -amv -k -DDD Network UPS Tools - Megatec/Q1 protocol serial driver 1.55 (2.6.5-Unversioned directory) ?? 0.000000??? debug level is '3' ?? 0.108370??? Initiating UPS shutdown ?? 0.108561??? send: 'C' ?? 0.150967??? read: 'NAK' ?? 0.151021??? instcmd: command [shutdown.stop] failed ?? 0.151162??? send: 'C' ?? 0.193506??? read: 'NAK' ?? 0.193598??? instcmd: command [shutdown.stop] failed ?? 0.193725??? send: 'C' ?? 0.236016??? read: 'NAK' ?? 0.236093??? instcmd: command [shutdown.stop] failed ?? 0.236127??? Shutdown failed! Probably the 'C' command has some unlocking mechanism. I remember around 15 years ago I had a cheap Ippon UPS which spoke the same protocol. This UPS fed a Windows PC and had the following problem: during Windows boot-up, when Windows started their own (that time, non-standard) COM-port plug-n-play enumeration of devices, the UPS with a small probability perceived this sequence as 'C' (or 'T', if I still remember right the protocol) and after 30 second switched off the computer being boot. I had to reverse engineer the program is this UPS and discovered commands to lock/unlock shutdown commands which solved the problem. Probably a similar mechanism is implemented in this my UPS but shutdown commands are locked by default. I do not insist on this version, I just want to share this idea. Maybe this is a known problem, then I would appreciate any pointer to find the solution. 2. Reporting battery.runtime and battery.charge. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ I am not sure this has to do with the support of this very specie, likely this is rather a bug in the driver or in the documentation (if one understand the documentation wrongly, this is probably a bug in there). With this bare configuration: [mv] ??????? driver = blazer_ser ??????? port = /dev/ttyS0 ??????? desc = "N-Power MegaVision 3000LT" and with a fully charged battery the driver reports the following variables: battery.charge: 100 battery.voltage: 109.44 battery.voltage.high: 104.00 battery.voltage.low: 83.20 battery.voltage.nominal: 96.0 device.type: ups driver.name: blazer_ser driver.parameter.pollinterval: 2 driver.parameter.port: /dev/ttyS0 driver.version: 2.6.5-Unversioned directory driver.version.internal: 1.55 input.current.nominal: 13.0 input.frequency: 50.1 input.frequency.nominal: 50 input.voltage: 209.8 input.voltage.fault: 225.1 input.voltage.nominal: 230 output.voltage: 230.7 ups.beeper.status: enabled ups.delay.shutdown: 30 ups.delay.start: 180 ups.load: 15 ups.status: OL ups.temperature: 41.5 ups.type: online Now I would elaborate the config and make use of the runtime guestimation. I added the following lines: runtimecal = 2000,100,5000,50 chargetime = 86400 default.battery.voltage.high = 109.6 default.battery.voltage.low = 84.4 default.battery.capacity = 40 I didn't do any real measuerements yet and these data are based solely on the datasheet of my batteries and common sense. Now I get battery.capacity: 40 battery.charge: 0 battery.runtime: 1 battery.voltage: 109.44 battery.voltage.high: 109.6 battery.voltage.low: 84.4 battery.voltage.nominal: 96.0 with battery.charge and battery.runtime slowly (very slow!) grossing. Is this expected? I would appreciate any help with these two problems. I would be happy to provide any details. Thanks and regards. Alexander. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20130811/10f0b056/attachment-0001.html>
Александр Безруков
2013-Aug-11 18:12 UTC
[Nut-upsuser] N-Power MEV-3000LT compatibility report and problem
Hello, sorry for messing up the things. I mean many copies of the same text in my previous message and mixing up the command names, it turned out that I forgot the protocol details after so many years. I found my records, connected a serial terminal to the UPS and found that the device itself works as expected so my problem cannot be explained with device incompatibility. Below is excerpt from my session. After "//" characters go my comments, these of course were not typed in. Q1 (205.7 225.1 230.7 015 50.1 2.28 41.5 00000001 // 205.7 is the real mains voltage, this is the problem of mains not the device F #230.0 013 096.0 50.0 S10R0003 ACK // UPS has shut down in 10 minues and restored power after 3 minutes, // as expected S03R0001 ACK C ACK // Shutdown has been successfully cancelled S03R0001 ACK // UPS has shut down after 3 minutes and restored after 1 minute, as expected S.7R0001 ACK // UPS has shut down after 42 second and restored after 1 minute, as expected. I see no problem with how the device communicates the Blazer/Megatec protocol. I must have found a bug in the driver. Regards, Alexander. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20130811/14093efd/attachment.html>
Charles Lepple
2013-Aug-11 20:44 UTC
[Nut-upsuser] N-Power MEV-3000LT compatibility report and problem
On Aug 11, 2013, at 2:12 PM, ????????? ???????? wrote:> I see no problem with how the device communicates the Blazer/Megatec protocol. > I must have found a bug in the driver.It is possible that the shutdown was tested with a different implementation of the protocol. What do you get from the "I" command? On Aug 11, 2013, at 11:25 AM, ????????? ???????? wrote:> So I believe the compatibility list deserves two new lines.Probably best to delay adding this to the HCL until we can get the driver to shut down the UPS properly.> # /lib64/nut/blazer_ser -amv -k -DDD > Network UPS Tools - Megatec/Q1 protocol serial driver 1.55 (2.6.5-Unversioned directory) > 0.000000 debug level is '3' > 0.108370 Initiating UPS shutdown > 0.108561 send: 'C' > 0.150967 read: 'NAK' > 0.151021 instcmd: command [shutdown.stop] failed > 0.151162 send: 'C' > 0.193506 read: 'NAK' > 0.193598 instcmd: command [shutdown.stop] failed > 0.193725 send: 'C' > 0.236016 read: 'NAK' > 0.236093 instcmd: command [shutdown.stop] failed > 0.236127 Shutdown failed!This behavior (where any previous pending shutdown is cancelled first) was introduced here: https://github.com/networkupstools/nut/commit/0eef5be7 I wonder if other Megatec-based units don't send a NAK if there is no shutdown pending? Also, maybe we can just attempt the 'C' command up to three times, then send the shutdown command outside that loop. Unfortunately, my Best Power UPS is not available to see how it handles this. Also, I am not at all familiar with the runtime calibration config variables. -- Charles Lepple clepple at gmail