Unfortunately i can not try the latest version - 2.7.1, no binaries available for win32. In builds 2.6.1 - 2.6.4 no driver named apcsmart-old, only man page, dedicated to them. i tried apcsmart from nut 2.6.1 - 2.6.4 with no success. Thank You.
14.01.2014, 17:29, "Michal Soltys" <[email protected]>: > On 2014-01-14 10:12, dstrr wrote: > >> Hello. >> Trouble to communicate with APC SmartUPS via serial port. >> UPS connected to the com1 port on windows host. >> Communication witch hyperterm works well. >> There is a log: >> >> YSM >> ^ASmart-UPS SC1000 >> n5S0713T63247 >> m03/29/07 >> L240.0 >> B27.10 >> >> apcupsd also can communicate with the UPS and works well. >> >> running apcsmart -a ups gives the following: >> >> com1: device reports different attributes than what were set >> unable to detect an APC Smart protocol UPS on port com1 >> check the cabling, port name or model name and try again > > All issues related to certain sanity checks (and some misbehaviour) > while setting up serial ports should be fixed in the current version of > nut. Is it possible for you to try current version of nut ? > > There should be apcsmart-old present in your build as well, so if it's > not possible - you can use the previous version easily. > >> ups.conf: >> [ups] >> driver=apcsmart >> port=com1 >> cable=940-0095B >> desc="test" >> >> Sysinternals Portmon captures the following activity on com1: >> >> 0.00009862 apcsmart.exe IRP_MJ_WRITE Serial0 SUCCESS Length 1: 59 >> Y >> 0.00001090 apcsmart.exe IRP_MJ_READ Serial0 SUCCESS Length 1: 53 >> S >> 0.00000950 apcsmart.exe IRP_MJ_READ Serial0 SUCCESS Length 3: 4D 0D 0A >> M [CR] [LF] >> 1.48775808 apcsmart.exe IRP_MJ_READ Serial0 TIMEOUT Length 0: >> 0.00010029 apcsmart.exe IRP_MJ_WRITE Serial0 SUCCESS Length 1: 1B >> [ESC] >> 0.00001117 apcsmart.exe IRP_MJ_READ Serial0 SUCCESS Length 1: 4E >> N >> 0.00000950 apcsmart.exe IRP_MJ_READ Serial0 SUCCESS Length 3: 41 0D 0A >> A [CR] [LF] >> >> Thus, apcsmart sends the Escape character, which is not recognised by UPS >> and returns NA. >> Is there a solution for this issue? >> Thank You and sorry for my English. > > The actual issue above was that when setting serial port, IGNCR was > ignored and the new driver expected that to be honored. It's fixed in > the current version (CR is always filtered now), but not in that > particular build. Current driver also allows to use both canonical and > raw modes, so should the former (default) fail, the alternative is > available. _______________________________________________ Nut-upsuser mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
