similar to: Tag on a schedule please

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 driver and pull request created, https://github.com/networkupst ools/nut/pull/404 tested and works fine. UPS configuration is needed, and included in the 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,

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

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

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 we have, we would prefer if the

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 address do you want on the commit, gmail or

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

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, > etc) , ID strings (serial number, etc), status flags (inverter on,

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

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?

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

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)

Hi guys, I wrote for Arnaud that I tested the liebertgxt2 driver in 2.4.3. I compare output of Richard's code, Spiros code and nut 2.4.3. Output of Richard and Spiros codes was same and right. Output of Liebertgxt2 driver isn't. Examples: Our UPS : Liebert GXT2-1000RT230 Model Name,Firmware version,SN,date of manufactured values was right. Fields

Hi All, Attached is a patch against nut-2.4.1 that adds a driver for the ESP2 protocol, as used by the serial port found on the Liebert GXT2. This driver is mostly based on: http://www.csc.liv.ac.uk/~greg/projects/liebertserial with additional bit field information from Spiros Ioannou. liebert.c at the above url has been tested by a few people to return the correct status data. Besides me,

Yeah, I have its datasheet (it's a Xantrex XW invertor by the way). I do not know why creating a more-or-less generic driver is an issue. Of course, there are Modbus beasts that can scare everyone but mostly one would need to read either intreger or float numbers out of Modbus registers in order to decide whether or not to start or stop the shutdown process. 24 ???? 2017 ?. 19:25:14

Hello all, During holiday revision of issues (hoping to tie up loose ends and get to NUT v2.8.1 soonish), an old https://github.com/networkupstools/nut/issues/50 ticket came to my attention - that some years ago "we" (as NUT community) wanted to create an unified driver for devices with a Modbus connection -- similar to `nutdrv_qx` doing everything about Megatec Qx protocol family

Hello all, During holiday revision of issues (hoping to tie up loose ends and get to NUT v2.8.1 soonish), an old https://github.com/networkupstools/nut/issues/50 ticket came to my attention - that some years ago "we" (as NUT community) wanted to create an unified driver for devices with a Modbus connection -- similar to `nutdrv_qx` doing everything about Megatec Qx protocol family

Hello Ted, 2013/9/11 Ted Mittelstaedt <tedm at mittelstaedt.us> > Hi All, > > About a month ago APC announced they were including MODBUS protocol > support in their new APC UPSes. The technical note on this is here: > > http://www.apcmedia.com/**salestools/MPAO-98KJ7F/MPAO-**98KJ7F_R0_EN.pdf<http://www.apcmedia.com/salestools/MPAO-98KJ7F/MPAO-98KJ7F_R0_EN.pdf>

On Jun 24, 2017, at 10:57 AM, Sergei Naumov wrote: > I was wonering if there is a driver that supports communicating with a Modbus aware device over IP. I have a solar/wind invertor that can broadcast its state and I would like to monitor the batteries. If they discarge to a certain voltage or come to a defined state, I would perform a shutdown. All of this information id provided in Modbus

Hi Ted there was a drift from the initial topic. worth a new thread! 2014-07-27 9:13 GMT+02:00 Ted Mittelstaedt <tedm at mittelstaedt.us>: > On 7/26/2014 12:18 PM, Arnaud Quette wrote: > >> Hi Eric, >> >> sorry for the lag, summer time... >> >> I'm first seconding Charles comments >> >> 2014-07-09 12:31 GMT+02:00 Eric S. Raymond <esr