search for: sivann

Hello, 1) I'm planning on adding lots of measurements to the driver liebert-esp2 + correct support for 3-phase systems. Should I make a large patch based on the last svn head or send you the whole file? Multiple patches per change are probably not practical in this case. 2) in http://www.networkupstools.org/doc/2.2.0/new-names.html there is no crest factor variable. Crest factor is very

I attach a patch for phoenixcontact_modbus.c This patch does the following: * Marks driver as DRV_BETA * Fixes stale data detection when cable is disconnected I can open a pull request if needed. Kind Regards, -Spiros p.s. please consider a faster tag/release schedule as currently linux repositories include old versions. Sure we can make packages ourselves, but it's better to have support

Hello, this is to let you know I will start working on a modbus driver for the PhoenixContact QUINT-UPS industrial DC UPS, model 2320461. https://www.phoenixcontact.com/online/portal/us?uri=pxc-oc-itemdetail:pid=2320461&library=usen&pcck=P-22-07-01-01&tab=1 I will reuse some parts of the nutdrv-modbus branch, but this will be a model specific driver, not a generic one. Unfortunately

Hi Devs, do you have an estimate for a new release date? We want to deploy linux boxes which will include support for the newly contributed phoenixcontact_modbus driver. As we would like to create a package for both CentOS and an embedded Linux device we have, we would prefer if the package was based on a official release. If 2.7.5 is not coming soon (say 1 week) do you have a suggestion of a

2009/1/22 Spiros Ioannou <sivann at gmail.com> > Cher Arnaud, > Hi Spiros, > I send you a demo that reads info from an Emerson Liebert > GXT2-10000T230 through the RS-232 port. This uses the "ESP-II (ESP 2) > Protocol". > Current supported data includes: measurements (voltage, temperature, > e...

2009/10/15 Farkas Levente <lfarkas at lfarkas.org> > hi, > i read your thread at: > > http://lists.alioth.debian.org/pipermail/nut-upsdev/2009-January/003772.html > > http://lists.alioth.debian.org/pipermail/nut-upsdev/2009-January/003775.html > we've got exactly the same problem that we need a nut driver for liebert > ups. is there any progress in this field?

...man page of the driver. Is there any indication on the usual time it takes for a driver to be checked/included on the master? (We are planning on setting up hundreds of those UPS boxes and it would be great to have an estimate) Kind Regards, -Spiros On 13 March 2017 at 13:18, Spiros Ioannou <sivann at gmail.com> wrote: > Hello, > this is to let you know I will start working on a modbus driver for the > PhoenixContact QUINT-UPS industrial DC UPS, model 2320461. > > https://www.phoenixcontact.com/online/portal/us?uri=pxc-oc-i > temdetail:pid=2320461&library=usen&pc...

On June 1, 2017 9:32:34 AM GMT+02:00, Spiros Ioannou <sivann at gmail.com> wrote: >Hi Devs, >do you have an estimate for a new release date? We want to deploy linux >boxes which will include support for the newly contributed >phoenixcontact_modbus driver. As we would like to create a package for >both >CentOS and an embedded Linux device...

On Sep 19, 2017, at 3:21 AM, Spiros Ioannou <sivann at gmail.com> wrote: > > I attach a patch for phoenixcontact_modbus.c > > This patch does the following: > > * Marks driver as DRV_BETA > * Fixes stale data detection when cable is disconnected > > I can open a pull request if needed. Looks good to me. Which email...

As I'm trying to find the correct values for other UPS models and I only see correct values, please use the attached driver while compiling nut and please give me an output from upsc. I would like you to give me the output from upsc along with the correct values you get from Multilink or the LCD. The only thing that must be wrong are the multipliers. Thanks for your effort, -Spiros

based on r2432, i took this with "svn diff --revision HEAD liebert-esp2.c" fixes: 1) new way to initialize model, firmware etc. variables, the strok way failed because some vars had spaces. (e.g. model "Liebert NX") 2) new multipliers for: frequency, nominal power. I get correct readings now, before I had 500 Hz, and 200VA and now it's ok for me. Test with your models. 3)

Attached. I also attach sample output from upsc OL & OB. I only tested it with 3-phase in/3-phase out ups. Thanks, -Spiros -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20100421/1d18bd30/attachment.htm> -------------- next part -------------- battery.current: 0.00 battery.runtime: 4860

Hi guys, I found the troblue and fix it! I attached the patch. The trouble was in the command reply buffer use. You compute the value that value = reply[6]*256+reply[5] <- it's wrong The right solution: value = reply[5] * 256 + reply[6]; And other bug, battery.runtime compute, you divide this value 60 <- it's wrong right value: divide 1.0 I continue the work on this

Guys hello, why are you not tagging? How will nut be included in recent OS distributions? Are you planning on abandoning nut? I committed the modbus driver years ago and since then I repackage nut myself for distribution with different package name and versioning. So I have a solution but what about all the others? Do you have other plans? You can auto tag weekly with a calendar-type versioning.

More detected parameters (attached), this time measurements for all 3 phases. I include only new discovered readings. Multipliers are wrong right now and need to be defined, and some commands are probably invalid/wrong, but most seem ok. I hope I find the time to implement those on the driver. What I'm missing is a way to discern between 1phase & 3phase (output) upses. output + read