search for: apc_modbus

...t; > https://github.com/networkupstools/nut/pull/2184 > > As before, a custom build of libmodbus may be needed for USB support (detailed in the earlier PR), but Serial and TCP may already be well served by a distro near you! Hi: I got a new APC SRT3000XL and tested the new driver "apc_modbus". the ups works fine with nut+apcupsd. the new driver "apc_modbus" has result below: 1. upsrw can write the variable "battery.date". but the new value will only show after restarting apc_modbus. and in my case the written data will shift one day. eg the command "ups...

...t; > https://github.com/networkupstools/nut/pull/2184 > > As before, a custom build of libmodbus may be needed for USB support (detailed in the earlier PR), but Serial and TCP may already be well served by a distro near you! Hi: I got a new APC SRT3000XL and tested the new driver "apc_modbus". the ups works fine with nut+apcupsd. the new driver "apc_modbus" has result below: 1. upsrw can write the variable "battery.date". but the new value will only show after restarting apc_modbus. and in my case the written data will shift one day. eg the command "ups...

...eady be well served by a distro near you! Jim On Sun, Oct 22, 2023, 01:08 Jim Klimov <jimklimov+nut at gmail.com> wrote: > Hello fellow NUTs :) > > It is my great pleasure to get a bit of sunshine from other people's > work, and announce that the initial pull request for `apc_modbus` NUT > driver has recently been merged to the main NUT codebase, so it would be > part of an eventual 2.8.1 release. Great thanks go to Axel Gembe for the > implementation, and to numerous community members for testing as well as > their bug-fix and feature suggestions. It is my underst...

...eady be well served by a distro near you! Jim On Sun, Oct 22, 2023, 01:08 Jim Klimov <jimklimov+nut at gmail.com> wrote: > Hello fellow NUTs :) > > It is my great pleasure to get a bit of sunshine from other people's > work, and announce that the initial pull request for `apc_modbus` NUT > driver has recently been merged to the main NUT codebase, so it would be > part of an eventual 2.8.1 release. Great thanks go to Axel Gembe for the > implementation, and to numerous community members for testing as well as > their bug-fix and feature suggestions. It is my underst...

Hello fellow NUTs :) It is my great pleasure to get a bit of sunshine from other people's work, and announce that the initial pull request for `apc_modbus` NUT driver has recently been merged to the main NUT codebase, so it would be part of an eventual 2.8.1 release. Great thanks go to Axel Gembe for the implementation, and to numerous community members for testing as well as their bug-fix and feature suggestions. It is my understanding that some tha...

Hello fellow NUTs :) It is my great pleasure to get a bit of sunshine from other people's work, and announce that the initial pull request for `apc_modbus` NUT driver has recently been merged to the main NUT codebase, so it would be part of an eventual 2.8.1 release. Great thanks go to Axel Gembe for the implementation, and to numerous community members for testing as well as their bug-fix and feature suggestions. It is my understanding that some tha...

...here are quite a few architecture and installation documents and README's (maybe a few too many for people just getting started, pull requests for simple entry points are welcome) :) In short, you would either have it installed via packaging prepared by your OS distribution maintainers (for `apc_modbus` in particular, you would need at least NUT v2.8.1), or built by yourself - in case of this driver and USB links, also building the custom libmodbus with USB capability, as per Wiki page linked earlier. Specifically in case of this driver and use-case, your best shot is "built by yourself&quot...

...upstools/nut/pull/2184 > > > > As before, a custom build of libmodbus may be needed for USB support > (detailed in the earlier PR), but Serial and TCP may already be well served > by a distro near you! > > Hi: > I got a new APC SRT3000XL and tested the new driver "apc_modbus". > the ups works fine with nut+apcupsd. the new driver "apc_modbus" has > result below: > > 1. upsrw can write the variable "battery.date". but the new value > will only show after restarting apc_modbus. and in my case the written > data will shift one...

...upstools/nut/pull/2184 > > > > As before, a custom build of libmodbus may be needed for USB support > (detailed in the earlier PR), but Serial and TCP may already be well served > by a distro near you! > > Hi: > I got a new APC SRT3000XL and tested the new driver "apc_modbus". > the ups works fine with nut+apcupsd. the new driver "apc_modbus" has > result below: > > 1. upsrw can write the variable "battery.date". but the new value > will only show after restarting apc_modbus. and in my case the written > data will shift one...

I have an Smart-UPS X 1500 (SMX1500I, USB) USB. I am looking for the APC_MODBUS driver. Thanks James -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://alioth-lists.debian.net/pipermail/nut-upsuser/attachments/20231209/e81b0a7d/attachment-0001.htm>

...gt; > >> > As before, a custom build of libmodbus may be needed for USB support >> (detailed in the earlier PR), but Serial and TCP may already be well served >> by a distro near you! >> >> Hi: >> I got a new APC SRT3000XL and tested the new driver "apc_modbus". >> the ups works fine with nut+apcupsd. the new driver "apc_modbus" has >> result below: >> >> 1. upsrw can write the variable "battery.date". but the new value >> will only show after restarting apc_modbus. and in my case the written >&...

...gt; > >> > As before, a custom build of libmodbus may be needed for USB support >> (detailed in the earlier PR), but Serial and TCP may already be well served >> by a distro near you! >> >> Hi: >> I got a new APC SRT3000XL and tested the new driver "apc_modbus". >> the ups works fine with nut+apcupsd. the new driver "apc_modbus" has >> result below: >> >> 1. upsrw can write the variable "battery.date". but the new value >> will only show after restarting apc_modbus. and in my case the written >&...

...5-25 > battery.runtime: 22320 > battery.temperature: 24.69 > battery.voltage: 54.53 > device.mfr: American Power Conversion > device.model: Smart-UPS 2200 > device.serial: AS1848260180 > device.type: ups > driver.debug: 0 > driver.flag.allow_killpower: 0 > driver.name: apc_modbus > driver.parameter.pollinterval: 10 > driver.parameter.port: /dev/ttyS0 > driver.parameter.synchronous: yes > driver.state: quiet > driver.version: 2.8.1.1 > driver.version.internal: 0.10 > experimental.output.energy: 0 > input.transfer.high: 127 > input.transfer.low: 106...

...5-25 > battery.runtime: 22320 > battery.temperature: 24.69 > battery.voltage: 54.53 > device.mfr: American Power Conversion > device.model: Smart-UPS 2200 > device.serial: AS1848260180 > device.type: ups > driver.debug: 0 > driver.flag.allow_killpower: 0 > driver.name: apc_modbus > driver.parameter.pollinterval: 10 > driver.parameter.port: /dev/ttyS0 > driver.parameter.synchronous: yes > driver.state: quiet > driver.version: 2.8.1.1 > driver.version.internal: 0.10 > experimental.output.energy: 0 > input.transfer.high: 127 > input.transfer.low: 106...

....date: 2023-11-25 battery.date.maintenance: 2028-05-25 battery.runtime: 22320 battery.temperature: 24.69 battery.voltage: 54.53 device.mfr: American Power Conversion device.model: Smart-UPS 2200 device.serial: AS1848260180 device.type: ups driver.debug: 0 driver.flag.allow_killpower: 0 driver.name: apc_modbus driver.parameter.pollinterval: 10 driver.parameter.port: /dev/ttyS0 driver.parameter.synchronous: yes driver.state: quiet driver.version: 2.8.1.1 driver.version.internal: 0.10 experimental.output.energy: 0 input.transfer.high: 127 input.transfer.low: 106 input.transfer.reason: AcceptableInput input...

....date: 2023-11-25 battery.date.maintenance: 2028-05-25 battery.runtime: 22320 battery.temperature: 24.69 battery.voltage: 54.53 device.mfr: American Power Conversion device.model: Smart-UPS 2200 device.serial: AS1848260180 device.type: ups driver.debug: 0 driver.flag.allow_killpower: 0 driver.name: apc_modbus driver.parameter.pollinterval: 10 driver.parameter.port: /dev/ttyS0 driver.parameter.synchronous: yes driver.state: quiet driver.version: 2.8.1.1 driver.version.internal: 0.10 experimental.output.energy: 0 input.transfer.high: 127 input.transfer.low: 106 input.transfer.reason: AcceptableInput input...

...py for `drivername -K` action which would take time again to detect and initialize the device), for example, although the latter is primarily just an option for future integrations and is not immediately beneficial out of the box today. Another important recent improvement is the addition of an `apc_modbus` driver to support the APC ModBus protocol (currently for read-only monitoring - I am not sure if development for commands and writable variables would land before the end of month). Generally you can preview the live list of notable changes since 2.8.0 release at https://networkupstools.org/doc...

...py for `drivername -K` action which would take time again to detect and initialize the device), for example, although the latter is primarily just an option for future integrations and is not immediately beneficial out of the box today. Another important recent improvement is the addition of an `apc_modbus` driver to support the APC ModBus protocol (currently for read-only monitoring - I am not sure if development for commands and writable variables would land before the end of month). Generally you can preview the live list of notable changes since 2.8.0 release at https://networkupstools.org/doc...

Seconding ... or firsting, considering the recent call to testing hidden somewhere in a recent mail post ;) Currently I'm aiming at cutting a NUT 2.8.1 release during October. As a bit of self-imposed retrospective: I did hope for a faster (quarterly or so) cadence when I made the 2.8.0 release, but then a few issues came up as regressions of 2.8.0 and it became a sort of crusade to fix

Seconding ... or firsting, considering the recent call to testing hidden somewhere in a recent mail post ;) Currently I'm aiming at cutting a NUT 2.8.1 release during October. As a bit of self-imposed retrospective: I did hope for a faster (quarterly or so) cadence when I made the 2.8.0 release, but then a few issues came up as regressions of 2.8.0 and it became a sort of crusade to fix