similar to: Patch for phoenixcontact modbus driver

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, 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

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

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,

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

Hi! 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 holding registers. This could of course be done

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

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?

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

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)

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,

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

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

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>

Hi, does anyone have any experience with UPSes managed with modbus/jbus protocol? I have a Socomec/Sicom Masterys MC unit, that is equipped with both RS232 and RS485 interfaces and, according to manual, supports JBUS-P and JBUS-PH protocols. I'd like to get some basic monitoring working, but I don't even know where to begin. Regards, -- Sebastian Zagrodzki Dzia? Sieciowy ICM,

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 "Application Note #176 Modbus Implementation in APC Smart-UPS" The APC "announcement" appeared on their site in their user blogs by an APC employee, here: