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.
_______________________________________________ Nut-upsuser mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
