[Nut-upsuser] Unable to detect an APC Smart protocol UPS. Windows. APC Smart protocol driver 3.04 (2.6.5-3723:3731M)

[Michal Soltys]

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.